Issue with X increment overwriting

[jjlee]

trying to read the x increment (resolution) value from the scope...

but if I change the resolution setting,(other than initial value displayed), it does not read the new resolution value, but stays at 1.25E-12 (ps)...

how should I fix, so that it will read whatever the current resolution of the scope will be displayed??

thanks,

[chilly_charly]

Don't understand where your problem is. Your wiring seems correct (although a bit messy... ;)) and your Xscale should display real values.
What do you mean by "...stays at 1.25E-12 (ps)..." ?

[jjlee]

thanks for the response....the resolution tracks the changing scale..so, it works now...

But, I have this VI works fine in LV setting, but once I create an application file (exe), it only loads once, then it does not enable/diable aggressors...

tried to create exe files three times, but still not working ....

need your help!

[AESulzer]

That's quite a project you posted! There are two things we will need from you in order to help you:

1. Simplification
2. More details

The first thing you need to do is strip down the program to figure out where the bug is occurring and to simplify the debugging process. I would first cut out all hardware code (instrument drivers and such) and replace it with some sort of simulated data. From there, you'll want to put notifications throughout your code so that you know where it is hanging up when you run it after you build it into an executable. You should be able to iterate through this process and get narrower and narrower in where this problem is occurring. Once you know where the problem lies, delete everything unrelated to it, and if the solution isn't obvious at that point, feel free to repost the issue and we should be able to help.

Kind Regards,

[jjlee]

thanks for your reply!

I think the main focus is on the "set config"

a couple of interesting observations;

1. amplitude and frequency setting of hp8648c works with changing values...(??)

2. None on the aggressor settings run again after initial program run

I wonder if that would be a decent scoping to narrow down the problem.

Best,

[AESulzer]

As I mentioned before, the biggest issue is that your project is so large that finding the bug would be like finding a needle in a haystack. Another issue precluding us from being able to help you is that your project makes calls to hardware that we don't have so we can not run it to see the behavior. I will repeat my previous post in saying that I think you should cut out all code unrelated to the problem and add some kind of code that will allow you to see where in the code the executable is hanging up. For instance, you could just use a string indicator to which write you could write the various stages of your code that the application is currently executing.

Also, a huge red flag is that I noticed you have not implemented any way for your code to stop once an error has occured (and that you never actually handle your errors at the end of your program). I would recommend that you add code to stop the main loop when an error occurs (status indicator within the error cluster) in addition to when you reach the "DONE" case (you can simply OR those two Booleans together).

Best of luck debugging and let us know if you still need help once you have whittled things down!

[jjlee]

I tried to simplify and put string indicators...

I am not sure how to stop the main loop when an error occurs. Could you share your insight?

converted the attached VI to EXE, but still having the same problem.

Thank you!

[AESulzer]

You can stop the loop during an error by checking the status element of the error cluster. You can then OR the error status with whatever other stop condition you want and wire the result to the loop stop condition. I've illustrated the concept below:

Message Edited by AESulzer on 04-25-2006 01:56 PM