Leaderboard

You need to have one of those fields at every level of inheritance -- if the child segment is non-default but the parent segment is the same as default, only the child segment will be written down.Before the smiting begins, let me lay out "how we got to why things work the way they work today". A) In LV 8.2, the first OO version, there was no XML support for objects. The only built-in persistence for objects was the Flatten To String primitive. B) When we save a VI, we save the value of diagram constants and default values for controls. To save space, we don't bother to write down those values when they are the default default value of the data type. C) LabVIEW classes are the first and only data types in LabVIEW where the default default value of the type can be changed. You can't tell LV "from now on, the default default value of an int32 is 1" but you can change the default default value of a class. This lead to a discussion of what the right decision should be about behaviors when the default default value is changed. Ultimately we settled on the behavior that a default value object should load as the default value, whatever the new default value happens to be. That decision has been criticized elsewhere on these forums, but four years later I'm comfortable that it was the right decision. D) That raised the question of representation of the flattened string. The format of an object saved into the VI and the format of the binary string didn't have to be the same, and we could have chosen different behaviors. But once we decided that objects would include their version number in their flattened representation, it made sense to have the unflattening of binary strings and the loading of saved VIs have the same rules for mutating data. Thus the default value should remain the default value. We now have two options: To not bother saving the flat data when it is default or to save the flat data and compare against the default when we load into memory. The former saves a lot of disk space AND has significant performance advantages. Thus we decided that the Flatten To String primitive, which creates a binary string of the data, should not write down the default value. E) When the XML prims were added in LV 8.6, we decided that the XML strings should again follow exactly the same mutation rules, and, again, the same performance trade-offs bent the discussion to not flatten the default value. F) XML is meant to be human readable, but, as others in this thread have noted, not necessarily human editable. If you provide an editor to your users for modifying the data, that interface will allow you to change the values without caring whether the value was written down or not. G) If you're using XML to share data between apps, you probably want to read this thread wherein I propose that you do NOT want to use the built-in LV XML primitives for XML that is going outside of LabVIEW, not because those prims are somehow flawed but rather that any built-in XML format is undesirable for data sharing (it's not a long thread if you want the arguments). H) Using XML has allowed people to write apps that circumvent the privacy protections of the object data -- flatten to xml, modify the xml, then unflatten the data again. Hiccups such as "the default value is just missing" throw a wrench into this blatant violation of app security. In retrospect, the ability to flatten to XML (and to binary string, for that matter) probably should have been restricted to member VIs by default (author of the class could remove the restriction, just like we did with Create Data Value Reference in LV 2009) so that most classes wouldn't allow this hack. I've been talking to folks about whether or not it is too late to fix this mistake.

Wow - that's a tricky one due to the very very low contrast. My first instinct is to suggest a different setup - if the item that you're interested in is the tan/pink thing that takes up te lower part of the image and the gray/white part at the top is just a background, then I'd change your lighting - you're using lighting that's on the camera side of the object you're looking at, but I'd go for a back light - remove all the lighting (or, at least, limit it) from the camera side, and out the item on a backlight (something like one of these from NERlite) - that will give you a high-contrast image that you can then binarize with an appropriate threshold - that will make the defect really stand out - then you can maybe determine the angle of the edge, and then try a parallel rake that's perpendicular to the edge. Shameless plug: You can find more infomation about all of these techniques, and more, in Image Acquisition and Processing with LabVIEW. <rant> You could try to solve the issue in software, but, if you can do it in hardware, you definately should! I've seen far too many setups where engineers have tried to apply countless software image transforms on top of other transforms to, essentially, get an image that the right camera/lense/lighting combination would have gotten much more consistantly. If you had a thermocouple on the end of 200 meters of noisy cable, you wouldn't try to filter out the noise in software - you'd fix the hardware setup. Image acquisition and processing is the same. As my old DAQ professor used to say: garbage in, garbage out </rant>