Compiling skips function delay

[sarunaszx]

Hello,

I am working with Labview and Newport Piezo actuator driver. It has library for controlling piezo actuators which works fine when I am working with non - compiled VI's. 

There is a function which discovers connected piezo controller and it accepts an argument Delay for discovery. It means that it waits a certain ammount of time to discover the device and if it is exceeded - it returns an error that no devices were detected. By default this time is around 5secs. 

When I am working with an uncompiled VI's, program waits for like 3s and connects successfully. However, when I compile it, it no longer waits (skips the wait time) and reports that no device is connected (but it is connected!). 

I tried disabling build optimizations and other build settings, but without any success. I am using labview 2014 32bit version. But it also happened on 2013 LbView. Delay time is hardcoded as a constant, 5000 ms. I attach the image of device discovery function. I do not include the whole project, since it is quite large and a bit messy. Any ideas where the problem is?

[Marco_Ge · Accepted solution]

Could you run you executable with the error out indicator visible in order to see if any error occurs?

You could also try to identify the dll which is used by the toolkit and put it inside the same folder that contains your executable.

[sarunaszx]

You were right indeed - it turns out that labview skipped 2 other dll's (wrapper and ethernet configuration) which were needed for this function.
I was expecting an error in compiled program, but I guess it does not return them the way it does in VI's (without an indicator). 

Thank you for your help, I have a functioning program now. It was a rookie mistake.

[Marco_Ge]

Very good.

When there is a different behaviour between source and exe, then at 99% it is some component missing or in a wrong place!

Have a nice day.

marco

[billko]

When building an executable, automatic error handling is disabled (among other things).  Best to learn how to manually handle errors now.

[sarunaszx]

Yes, indeed. However, my applications tend to be really large and complex - mostly due to my messy program style. It is difficult to maintain proper error handling in this case. 

[billko]

---

@sarunaszx wrote:

Yes, indeed. However, my applications tend to be really large and complex - mostly due to my messy program style. It is difficult to maintain proper error handling in this case. 

---

I have to put it bluntly and say that's no excuse.  That's like saying you're not going to wear your seat belt because it's difficult to reach behind your seat for it.  Without proper error handling, you won't even know when something is not working.  You might not even know you are taking bogus data.

For instance, you might not even have needed to post here if you had proper error handling.  One of the worst things a rook can do is get lazy on the error handling.

This isn't even a LabVIEW thing; it's just good programming hygiene.  😉

[sarunaszx]

I accept your criticism, that is indeed the case. I am familiar with programming hygiene but it is a whole different thing in labview.

I usually try to make my code modular with subVI's and flat sequences, but programs usually get bigger and bigger because I am adding new functions, which were not initially planned. This is where my error handling and hygiene fails.

Also, I have self-taught myself programming labview, because I needed it. And for most applications in laboratory, it is enough that a software works, it doesnt have to be perfect.

This is the next step for me - learn to create understandable block diagrams that can be edited in the future and maintain proper error handling. The main difficulty now is listening to button state changes ;/ On event structure is inconvenient and shift registers with variables make everything messy.

P.s. if you have any source of information about error handling and labview hygiene, I would be grateful if you shared.

[billko]

Self-taught?  Not so bad, then.  There are links to some tutorials that would be of interest to you on the main page of this forum on the right side.  There's also an extremely helpful book, "The LabVIEW Style Book", that would be of immense help to you.  It was my bible back in the day.  Although it's a bit dated physically, the fundamentals that it teaches are timeless.

One little-discussed advantage of having subVI's - beyond making the code easier to read and more self-documenting - is that your error code will contain the vi path that it occured in.  If all you have is one VI, it won't tell you much, but if you have subVIs, you can narrow things down considerably.

Good luck!