LabVIEW claims that VI was changed, when it was not

[Sebastian.Weber]

Hi!

We have several computers, and each is used to develop a common project. SVN is used as version control, and everything works fine, so far.

The project has one base class with many child classes, and while child classes are added an modified often, the base class itself has not been touched for a long time, now.

But.. there is a single method VI in the base class which claims to be modified as soon as someone pulls an SVN update and starts developing, and when this VI comes from another computer. After the next commit and update on an other computer, LabVIEW will change it there, again.

The point is: We did not change (nor open) this VI. We even separated compiled code from the VI to overcome minor differences in compiled code.

LabVIEW says that a break point was set or cleared, and indeed the VI contains a single break point, which is used as assertion in case of unexpected data. But other VIs also have break point, and don't show this problem. This is also why I can't provide a sample, since it only happens with this one VI.

Any idea what could be the reason?

[crossrulz]

---

@Sebastian.Weber wrote:

LabVIEW says that a break point was set or cleared, and indeed the VI contains a single break point, which is used as assertion in case of unexpected data.

---

So you have something in there that was used for debug.  If you changed the setting on that breakpoint (enable, clear, remove), it will cause the VI file to change.

[Sebastian.Weber]

Well, as said, the breakpoint is used as assert function, is always activated, but usually never fires. We do not open the VI, it is simply loaded by LabVIEW because it's used as sub-vi somewhere. When saving the project, this vi is also saved.

[McQuillan]

Update: My bad - You've already mentioned about separating the compiled code

I used to have this issue because LabVIEW has a tendency to want to touch everything. I solved it by separating the VI to the compiled code and I haven't had any issues since.

http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/separate_compiled_code/

[aptivo]

Are there any external dependencies like dll-files, .net or ActiveX involved? If a version change occures (Windows update e.g. updates dependency) LabVIEW tries to update involved VIs as well.

[Sebastian.Weber]

Hello!

No, This VI contains plain labview functions, only. It doesn't even use references or so. The code is absolutely plain and simple, with the exception that there is a case structure with a breakpoint, which only fires if some inputs are absolutely odd.

[billko]

To me, this is like purposefully stopping your car by driving it into a tree and complaining about the body work that needs to be done afterwards.  Handle this issue with code, not with something designed as a debug tool.  To me, this is "lazy" programming.

[Sebastian.Weber]

Errorhandling is there to prevent or limit the damage on a car while driving. An assertion is there to forcefully stop the mechanic to try to start the motor when he assembled the camshaft wrongly. That's the point, it will never happen during normal operation, only when the programmer did something very wrong. (And... one could discus if an assertion is bad practise or not, this doesn't answer the question...)

[billko]

---

@Sebastian.Weber wrote:
Errorhandling is there to prevent or limit the damage on a car while driving. An assertion is there to forcefully stop the mechanic to try to start the motor when he assembled the camshaft wrongly. That's the point, it will never happen during normal operation, only when the programmer did something very wrong. (And... one could discus if an assertion is bad practise or not, this doesn't answer the question...)

---

Well, it does provide a solution; just not the one you want to hear.  Handle whatever it is that brings you to the break so you don't have to break.  A break should never be a part of released code.