LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Weird LabVIEW... VI is Editable In Run Time

Solved!
Go to solution

Thanks for clarifying that.

 

Going way out on a limb here.....  Perhaps a .zip isn't the best choice for deployment.  An installer for a source distribution would be much safer.  What makes me shudder just a bit is the question "What zip tools are on either end?"  With win7 and later explorers being able to open files inside a .zip I'm not too surprised if a few things go wrong.  I'm really surprised that it broke the way it broke but not too surprised it broke.  Something in the Project's app instance definately got confused.


"Should be" isn't "Is" -Jay
0 Kudos
Message 11 of 15
(1,004 Views)
Solution
Accepted by Shazlan

We've finally fixed it... by sending the files one-by-one!

 

I don't normally share the source code, unless the customer wants it. In this case, they do. In such cases, I've taken similar approach so many times in the past and has been working without failure. It didn't struck me to check and see what kind of zip program they are using that cases this. I'll ask them during our next concall.

 

Anyway, honestly, I've been hoping that LabVIEW has this capability similar to some other PLCs where the code can be modified on-the-fly - without the need to stop the program first. It would be very cool and definitely will help troubleshooting much faster and easier. This bug, as much as it is such a pain, shows that this is possible. Now, if only the HMI is working and not editable as well. I could have taken the full advantage and turn this bug into gold huhuhuhu...

 

 

Shazlan

0 Kudos
Message 12 of 15
(981 Views)

Erm, no.

 

Just because the IDE gives you the feeling that the code is editable while it is running, without a framework to actually update the running code (something which to my knowledge certainly does not exist) you're out of luck.

 

It's an interesting bug, but it won't give you superpowers to edit running VIs.  What it WILL give you is corrupted memory and damaged VIs.

 

Shane

0 Kudos
Message 13 of 15
(971 Views)

An update. We've tried changing the zip program but the result still is the same. However, one thing that we realized is that this weird behaviour is only seen when the VIs were loaded in LabVIEW 64-bit and not 32-bit. I've done in the past where the development is done in 32-bit but the actual program runs in 64-bit. I was told that the VIs can be used interchangeably. I'm not sure on the mechanism of how LabVIEW handles the VI so that it becomes interchangeable but could the zip and unzip screw up the 64-bit meta data of the VIs or something?

 

 

Shazlan

0 Kudos
Message 14 of 15
(943 Views)

All very interesting, but it's also all conjecture. At the end of the day no-one will be able to identify the true source of this, even NI, without the actual VIs you're talking about. I suspect you don't wish to share your source code so that we can try to replicate the problems?

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 15 of 15
(908 Views)