Jeffrey Habets

QUOTE (Yair @ Mar 18 2009, 07:28 PM)

Jeffrey said he didn't get the out of memory error when using the unflatten primitive. Assuming he tried it on the same file (did you, Jeffrey?) shouldn't the binary file primitives do the same?

Yes, I did try it on the same file.. And I also was under the assumption that the binary primitives did basicaly something like reading the file and then unflattening. But reading AQ's response I realize that it isn't that simple in all cases.

When I read the file as a string and offer that string to the unflatten primitive, LV already has a lot more information (namely type and size) then when it should read the information straight from the file. So in this case LV knows how much memory to alocate.

Looking at the nature of a flattened class (and give the fact that my class data is not of variable size (e.g. no arrays or strings in it)), and seeing that the first 4 bytes determine the number of inheritance hierarchies my guess is that this is where LabVIEW chokes on. This number should be 1, since my class has no ancestors, but in my particular test case where I try to read a text file as binary, this number was very high so LabVIEW probably tried allocating memory for a couple of million class data clusters and this obviously results in an out of memory error.

QUOTE (Aristos Queue @ Mar 17 2009, 08:38 PM)

It's not a bug -- it is LV doing exactly what you told it to do. This behavior applies regardless of the data type you're unflattening, including LV classes. And it is not unique to LabVIEW. Try renaming a random file as ".png" and then ask a paint program to open it. You'll get any number of strange behaviors.

Thanks for your input.. After reading this and the LVClass Data Storage Format wiki article I see that this problem can occur. Untill I read the wiki article I was under the impression that classes saved more information about itself when flattened.

QUOTE (Aristos Queue @ Mar 17 2009, 08:38 PM)

Ofcourse, I use that always as an extra check. But I'm not a fan of just plain extension-checking because it's pretty easy to change extensions and there are likely to be other file formats with the same extensions out there. I actually ran in to this finding accidently while migrating a program's storage format from readable text to binary, while needing to keep the extension the same for both.

QUOTE (Yair @ Mar 17 2009, 06:58 PM)

I assume that if you try it by using the method NI shows in its examples (using the datalog functions) it will work, but it might not. Personally, I flatten to a string and then save that string. You can try doing the same and seeing if the unflatten node throws the out of memory error.

In general, though, I would agree that this is probably a bug and that LV should recognize you simply did not point it at a class file.

The unflatten node doesn't give the out of memory error, instead it returns an error (1527, Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW.) which seems the correct behaviour I also would expect from the read binary primitive. (Since the(un)flatten thing is probably more or less what the binary read/write primitives do under the hood anyway.)

I can actually read the class data written using the binary write by reading it as text and unflattening the string. So there's my workaround for now.

Thank you guys for your thoughts, I'll file a bug report on this issue.

QUOTE (neBulus @ Mar 17 2009, 04:19 PM)

I experienced that myself and put it in the "Don't DO THAT" collumn. That is the same effect as what heepens when you (or LV 7.0 when quickly closing and opening files, no you don't have to believe me ) mix up you file references for files of two different file types. The File primative trusts us that the file is of the type specified.

Ben

True, and for 'normal' (non class) data I would add a header containing file type and versioning information and read that first before attempting to further process the file. I'm using classes here to make life easier and let them do the versioning. I'd expect LV to be smarter when loading the data, because it has all information it needs in the class datatype.

As a matter of fact, I just tried the same with a cluster wired to the Read binary primitive and there I get a more expected result when opening a file with other (than the cluster format) data: LV returned error 116, Unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data. It should throw the same error with classes.

Hi,

I have a case where I use the power of LV-Classes and their automatic version mutation capabilities for storing data to a flat binary format by just wiring the class wire to the "Read to binary file" primitive. Writing/reading class-data of different class version works like it should. However when for some reason the user would select a non-class file (e.g. some text file), I would simply expect the "Read from binary file" to return some error I could act upon.

Instead, LV throws a "Not enough memory to complete this operation" dialog at me, then when I click Ok on the dialog, after a really long (10's of seconds) timeout I get error 4, End of file encountered out of the "Read from binary file" primitive.

I'd qualify this as buggy behaviour. What are your thoughts?

Case: given an XControl that has some custom property. If we write to the property, the facade will be called with the Display State Change event. The XControl determines from the property write that the XControl's data needs to be changed, so it does. (Illustrated in the example by applying the random value to Data Out.)

Now when the VI using the XControl uses a property node where the first property written is a custom property (which as a side-effect induces the value change as described) and the second property is the Value which we write a value to (5 in the example), then when we read the Value-property again after that we would expect to see the value we wrote before (5). Instead we get the value that was induced during writing of the first property (Range in this case).

If we change the example code (see disabled case) to first write the custom property and then write the value property using a separate property-node everything works as expected.

Download File:post-906-1236990414.swf

Download File:post-906-1236987840.zip

For what you seem to be doing here (do the same action with just a slight difference depending on what item is selected) I think buttons are the wrong controls to use for your use-case.

Typically I would use a (multi-column) listbox (if you also want to categorize, use a tree-control) and fill it with the data from your Excel sheet. Then, the only event you need to catch is the double-click in the list and read the values from the clicked row.

You certainly won't be able to get the 20kHz deterministically since the devices you mention are all programmed I/O.

I don't know about the capabilities of the counter/timer on those devices. (I do know that with the counters on an M-Series device it's pretty easy to generate the digital pulse signal you need.)

As Yair said, I would give NI a ring, they should know.

The problem will be resolved in a next LabVIEW release..

NI Offered me two possible workarounds of which I used the second one and this works for me:

1. Set resource\Framework\Providers\lvrio\crio.llb\_nicrio_getModuleXML.vi and _nicrio_getModuleXMLForRSI.vi to non-reentrant. Since these are password-protected VI's that's not really an option for normal users.
   
2. Configure the Open FPGA Reference node to use the bitfile instead of the FPGA VI.
   

QUOTE (LV_FPGA_SE @ Jan 6 2009, 01:08 AM)

I had not tried this before, but decided to give it a whirl as I see LV classes being a great interface tool for the FPGA. I put together a simple class to talk to my FPGA, but did not run into the problem you described.

I have attached my project files for reference. Can you give these a try and let me know what happens?

Download File:post-3370-1231200448.zip

Thanks for testing this. I tried your project, and it loads fine here.. No problem.

So it seems my problem is probably not (only) class-related. Maybe it has also to do with the kind of FPGA-target configuration, I don't know.

I've attached the stripped-down project that reproduces the problem. This is also the project send to the NI AE and now under investigation as CAR#: 139277.

Note that my classes are GOOP3 (Endevo) which is basically a LV native class with some extra. The problem isn't in the GOOP3 framework for sure, since I can also reproduce it with a LV native class in this same project.

The project as attached will open without a problem because the FPGA interface nodes are commented out. To reproduce the problem, open FPGA0_DAQ.lvclass:FPGA0_DAQ_Create.vi (under Hardware) and enable the stuff that is now disabled. Save the VI and project, then close and re-open the project.

Download File:post-906-1231252734.zip

I would like to encapsulate my FPGA access in a class, but it seems LV can't handle it. If I have one (or more) FPGA interface nodes in one of my methods, save and close the project and open it up again, LV crashes in exec.cpp line 1704.

I reported the problem to NI and am waiting for their response, but in the meantime I'm curious if someone else has bumped into this problem. I'm using LV8.6.

QUOTE (Val Brown @ Dec 18 2008, 06:58 AM)

So, in a sense, it's like using componentized code from MS, eg COM object and ActiveX. You can use them but not edit them.

OK far enough but what really then is the difference?

Not really.. You can actually edit all relevant class-code (the methods and attributes) without having the toolkit(s) installed (unless the programmer of the class locks the BD's).

You can even add new methods without the toolkit (although it's of course a lot easier and faster if you have the toolkit).

QUOTE (dblk22vball @ Nov 25 2008, 10:40 PM)

For some reason it will not store the correct row though. It always defaults to 0, instead of the selected row. I attached my updated vi's.

I tried updating the row in the Data and Display clusters, but it does not seem to be saved for some reason.......

In your Listbox Value Change you need to tell LV that your state and display data has changed (as you do when you handle the button clicks).

To make it even simpler I would simply read the values of the listbox when the buttons are clicked. No reason to save the rows in your state and/or display date in this case.

QUOTE (dblk22vball @ Nov 25 2008, 08:19 PM)

I attached my xcontrol, as I cant seem to get any of the items to go anywhere. I am sure I am missing something so very simple.

You should use the listbox's Value instead of the Active Row property.. The latter one serves a different purpose (setting/getting row specific attributes, also see Ctrl-h when you hover over the property.)

I also recommend you use the Value Change events (for both the listbox and booleans) to detect the value change. That's what it's for and I think it's the only way to know for sure you have the correct (updated) value at your disposal.

I'm a bit short on time now and haven't really given any thought on your description and if it should work or not that way.

But here's what I do in my code and this works like a charm..

Thread.vi is in my case a private method and thus not dynamic dispatch, but it in turn calls dynamic dispatch methods on the DAQ class which are overriden in the child classes. I think this should do the trick in your case also.

QUOTE (Aristos Queue @ Oct 5 2008, 08:47 PM)

If the generic probe did that, there would be riots over it taking up too much screen space. We created custom probes so that everyone could build what they needed/wanted/can't believe LV R&D didn't give them.

It's a good thing that we have the custom probes.. And I have them on my own system, but often I'm debugging on a client's system and I'll have to do with the default probes. Imho, having the custom probes should not mean the generic probes don't have to evolve further with new versions of LV. Things like having the radix visible/setable and basic formatting should be available in the generic probes. The probe window doesn't have to be as big as in my example (I just used the conditional probe as an example), so screen real-estate isn't a problem here.

I've submitted this to NI's product suggestion.

Let floating point numeric probes by default display all digits of precision for that particular data type.

In a recent project I've spend hours and hours looking for a bug of which it wasn't directly obvious to me that it was caused by the floating point lsb rounding errors because these are basically masked by the default setting of 6 significant digits. I think this is a good default for FP-controls, but not for probes which are used for debugging purposes. In my case it would have saved me tons of time.

Now, I imagine it is not always wanted behavior to have full precision in a probe, so best thing would probably be to have a control on the probe FP to set the nr of digits of precision at runtime. I can create a custom probe for that, so my problem is solved, but it would be nice to have this available on the default probe. I imagine more people are caught by this 'problem'.

Well, after a quick glance at the code, I see at least one race-conditions that could cause this..

The local variable state in the lower loop could be read before the value is actually initialized in the upper loop. Since the initial value of state will almost always be stop (except for when you first run the VI after opening it, it will have the default value then), this is probably your problem.

So you will either have to initialize this state before you enter both loops, or better, use an occurence to stop the second loop. Here's an example:

QUOTE (crelf @ Sep 8 2008, 04:00 AM)

Oh - and this is accessible through the Help menu too...

Yep, I now all of these 'tricks'.. But I still would like to see possible generated error codes with the function descriptions in the manual. In some cases I want to present a custom error message to the user (with explanations on what to do to resolve, etc.) instead of just presenting the sometimes (to the user) cryptic default explanations. Now I often just trial and error the different use-cases I want to catch and note the error that needs to be filtered.

QUOTE (crelf @ Sep 8 2008, 04:00 AM)

Yeah, I regret it already..

The error are grouped in the LV help:

I do agree that it would be a big help if possible generated error's would be mentioned with the VI/function help instead of a seperate place. Particularly for HW I/O functions.

QUOTE (crelf @ Sep 1 2008, 05:56 PM)

Amen!

Amen to everything created by mister Mark Knopfler!

I must say I normally just code with the radio on.. But if it's not the radio it's MK/DS or the Eagles.

Sigh... I wish I didn't use OOP as long as I do... Now I don't have a valid excuse to go.. :thumbdown:

Who's teaching?

Well, I think it should be doable.. I've done it within the same project (I think it was in LV8, where there was no duplicate option yet).

You should make sure that that you copy the complete item <Item Name="YourBuildName" Type="EXE"> including the closing tag within the <Item Name="Build Specifications" Type="Build"> tag. Then inspect (and if necessary edit) all property tags of your buildspec to see if they relate to stuff that is actually in your project.

I've done the same with DAQ-Tasks in recent projects and it is really important that everything that is refered to is actually present in the project. It's also important that you don't introduce duplicate names/paths etc. by copying tags.

It's actually a problem of the Export Waveforms To Spreadsheet File itself (I looked at the 1D polymorphic instance of it, haven't checked the others).

With every call, it writes one row of (empty) data to many.. I think the problem is the Incr function (see attached picture), although I haven't checked if it would break other functionality of the VI if it would be removed.

Question to NI would be, is this expected behaviour or is it a bug. I would think the latter.

QUOTE (Ton @ Jul 26 2008, 11:28 AM)

The application builder should have 'Conditional disable structures' options.

Amen to that..

QUOTE (Ton @ Jul 26 2008, 11:28 AM)

Imho this is already possible.

Right clicking the splitter gets you to the visibility property of the label for the splitter as well as the adjoining panes. From this menu you can also open a properties dialog for the panes and change the label there, which is easier if the label is obstructed by controls on your pane.

The splitter itself though doesn't seem to have a properties dialog. I wonder why, since all other controls have one.