Leaderboard

I found a problematic issue with the behavior of LVOOP class constant values. LVOOP constant values get cleared when the default default value of the class private data is changed to the same value as the constant value. Let's make some definitions: Class default value: The default value of class private data Default value class constant: LVOOP class constant, that has a specific default value flag. The constant behaves as by-reference object that refers to the class default value global. When the class default value is changed, the default value class constant is changed in synchrony. Non-default value class constant: LVOOP class constant with non-default value. The value behaves as any by-value object. It has its own value that does not depend ony the default value of the class, except in the problematic case described below. The LVOOP class constant can get a non-default value when you paste a previously copied value to it using Data operations -> Paste from shortcut menu. Class developer: An organization or developer that is responsible for developing and maintaining a class. Class user: An organization or developer that is using the class developed by some class developer. Consider National Instruments (class developer) has developed a class representing an IP connection to some IP address. Internally the class represents the IP connection with a IP address string constant in class private data. NI has initially set the "default value" of the class private data to be 0.0.0.0. Assume you (class user) as a non-NI developer have used a class constant of this connection class labeled loop back on block diagram and the value of it is non-default 127.0.0.1 representing a loop-back connection. Now NI decides they want to change the class default default value from 0.0.0.0 to 127.0.0.1. The issue here is that this change by NI will clear the value of your non-default value block diagram class constant and replace it by a default value class constant.Now NI decided that 127.0.0.1 is not a good default default value for the connection class and sets it to be 0.0.0.0 again. How this affects your program. Well, LabVIEW will not recover your initial value to your loop back class constant, i.e. 127.0.0.1, but instead keeps the default value. As a result, your loop back class constant no longer represents a loop back connection but a connection to non-existing IP-address 0.0.0.0. The behavior I expect would be that the value of loop back class constant on block diagram would always remain 127.0.0.1, even when the class private data default value is changed to the same value. You can replace the roles NI and you with you and your client. The issue here is, the constant values should never be cleared. If they really need to be cleared for some reason such as the class private data having changed structure, LabVIEW should definitely warn the developer that the constant values may no longer represent the data they used to. What happens here really is that when LabVIEW notices that a non-default class constant has the same value as the default value of the class, it replaces the constant value with a reference to the default value object. So the constant no longer is a constant representing its initial state but becomes a constant that stays in synchrony with the default value object. Once the default value object is changed, the constant value will also also changed. I think that LabVIEW should follow the principles below Theorem 1: A block diagram constant with a non-default value should always represent the same state that it initially had, irregardless of what changes has been made to the default value of the private data. Initially a red apple should always stay a red apple and not implicitly become a green apple even though the default color of apples is changed to green. This is what is currently happening in LabVIEW. Apple block diagram constants explicitly specified to be red apples are turning into green apple constants under certain changes of the default value of the class private data. Theorem 1 is broken by the fact that class constant state can change from red to green apples. Theorem 2: Initial and final revision of a class A,call them A1 and A3, are identical, but an intermediate state of class A, call it A2, is not identical to A1 and A3. Code compiled using class revisions A1 or A3 should execute identically irregardless if the code has been compiled against intermediate state A2. Theorem 2 is broken as you can revert the class to its initial state, still the changes in the class between initial and final state change the code using the class. Theorem 3: There should be no difference if code using a class has or has not been in memory when editing a class, if the class interface does not change.Once the code using a class is loaded in memory together with the latest revision of the class, the code should be updated always to the same state. Theorem 3 is broken as if code has been loaded in memory when a private data default has been changed twice, then the state of the code is different than the state of the code that has only been loaded into the memory when the class has reached its final state. So what I propose is that a class constant always has either a default value or a non-default value. The non-default value can equal to the class default value, but as far as the constant is concerned, the value is still called a non-default value. That is the value of a constant does not change from a by-value state to a by-reference state, unless explicitly changed by the class user. When the default value of the class private data is changed, the values of block diagram constant remain untouched. That is constants that already contain default value still contain the default value in the future. The constants that contain non-default value still contain a non-default value even if the new class default value equals to the constant non-default value. The important thing here is that the constant with non-default value has been explicitly set by the developer to be at some state and this state should be persistent no matter what (possibly another) developer does with the default value of the class private data. Once you paste data to a constant, it automatically gets a non-default status. The same would apply to indicators, once LabVIEW have written data to an indicator(control), the value of the indicator (control) would be non-default irregardless if the value actually equals to the class default value. Only when you want to clear the value back to the class default value, there could be a right click menu option Data Operations -> Reset to class default value. Let us take still another example of the current behavior. We are developing an natural number class. Initially we set the class default value represented by integer to be 0. We add a method +1 to the class and implement it by adding a class constant with non-default value 1 together with input data using another class method Add. We then accidentally change the default value of the class private data integer to 1. Accidentally! This clears the non-defaultness from out constant on +1 method block diagram. The constant gets the flag default value. Now we immediately notice out accidental mistake and correct the mistake by returning the default value of the class to0. Immediately. But the harm has already been done. The +1 method no longer functions as expected but now becomes +0 method instead. Is this really what we want? No warnings. Nothing. Just somewhere under the hood things implicitly change and we know nothing at all that we just broke our code. Everything that here applies to class constants applies to class controls and indicators, I think. I want to raise discussion. Should current behavior be changed in LabVIEW or do you think the present behavior of class constants is correct?

Hi!, I've been aware of this community for many years now, but have never got around to joining. Anyway, I think it's time to become more proactive. I'm an optics and imaging guy. Up until recently I've been a troll hiding in the basements of various universities around the world. All of a sudden I find myself in a new role as the LabVIEW vision guy for a big company in California. So hopefully I can help people on here with their vision problems, while I'll likely be needing help from people in other areas. I'm looking forward to working with you all and getting to know some folks who share my enthusiasm for LabVIEW. I've got hundreds of pieces of code from my basement troll days, for all kinds of things, so when I get a chance I'll tidy it all up and throw it up for general consumption. Cheers!

Looks like Mars.

You can check out the code here. I have also attached some code to calculate the XMODEM CRCs as well as the normal CRC-16.I have also attached the XMODEM-VISA.llb that I used. I am pretty sure this is the same llb referred to in the link I posted but if I recall I added the support for 1K transfers. Calculate CRC-16 (File input).vi Calculate CRC-16.vi Calculate XMODEM CRC-16 (Buffer input).vi Calculate XMODEM CRC-16 (File input).vi Get CRC-16 Table.vi Calculate CRC-16 (Buffer input).vi Xmodem VISA.llb

vi.lib\platform\icon.llb\Read Icons from ICO File.vi will read in an icon file into a cluster and also into a Picture control. It's actually what is used in the old Application Builder to support custom icons. Note that there are limitations as to the bitdepths supported here but the Picture control functions should be able to deal at least with 1, 4, and 8 bit icons. I would expect this library to not work well with the XP style icons inside some icon file but the rest should be fine. Rolf Kalbermatter