11-10-2008 05:47 AM
Hello,
Do you know how to make a XControl give a numeric value like Tick Count (ms) ? I think that is not that obvious. Tick Count is typically a node which value changes at every moment based on external parameters.
See the attached example. When a VI containing the XControl is "Run when opened" then the returned value is always zero, instead of Tick Count. This is related to the default value of the XControl data extracted on the Block Diagram before the Facade VI is called. Note that I need to use a XControl for other reasons, not a SubVI for instance or else.
Does anywone know how overcome this zero systematic value (still using a XControl) ?
Best regards
LabView 8.6 - Windows XP SP2
11-10-2008 10:04 AM
I think what you see is a bug!
Sorry,
Ton
11-10-2008 10:51 AM
Thanks at least for the confirmation it is a bug . If you are a certified Labview developper, are you willing to report this bug so that it will be corrected in next versions of Labview ?
Regards
11-10-2008 01:07 PM
Everyone can report a bug (not just certified LabVIEW developers).
I'm not quite sure what the bug description will be but I will put it up on the LabVIEW bug list.
I think the description will be 'XControl facade VI is not triggered in Auto-run VI'
Ton
11-12-2008 10:48 AM
Hello Julian3,
Thanks for using the National instruments forum. The behavior that you observed is not a bug of LabVIEW. In fact, it's due to the time of loading the xcontrol, and it is an expected behavior of LabVIEW. It takes a certain time to load xcontrol, and depending of the size of the xcontrol. If you look the attached VI, I just added a temporization function (100ms) before calling the xcontrol and it solved the problem on my computer. If it doesn't work you, try to increase the time the delay.
Best regards.
Maxime R.
CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
CTA - Certified TestStand Architect / Architecte TestStand Certifié
11-12-2008 10:54 AM
MaximeR wrote:
Hello Julian3,
Thanks for using the National instruments forum. The behavior that you observed is not a bug of LabVIEW. In fact, it's due to the time of loading the xcontrol, and it is an expected behavior of LabVIEW. It takes a certain time to load xcontrol, and depending of the size of the xcontrol. If you look the attached VI, I just added a temporization function (100ms) before calling the xcontrol and it solved the problem on my computer. If it doesn't work you, try to increase the time the delay.
Best regards.
Hmmm.....
That is the number one indicator that there is a race condition somewhere. Sorry to play devils advocate on you but that sounds like a kludge to avoid a bug.
" expected behavior of LabVIEW"
Can you point at some documentation to back up your statement?
Ben
11-12-2008 11:28 AM
I agree with Ben,
There is a specific event triggered when a VI is loaded into memory (Display State Change) and one when the VI started executing (ExecState Change).
Both of them should update the BD value of the XControl.
Ton
11-12-2008 12:24 PM
Hello,
We already worked on the time to load Xcontrol with the R&D. Loading a Xcontrol is different than a VI, and we can't determine how much time it would exactly take but this is expected behavior as the increase is linear with the size of the Xcontrol and when X control is loaded it makes numerous calls to the Facade.vi and all these calls are mainly asynchronous in nature and also that the calls to the facade VI also may result in the redrawing of the Xcontrol. Again we can't give an exact time figure on how long does it generally take. However, in this case it seems to be expected behavior.
You can remark that when the VI was load one time and that you don't close LabVIEW, you can reduce the delay because the Xcontrol is already in memory. But you need to keep a delay due to the redrawing of the Xcontrol. When you use a lot of Xcontrol or a big one, it's better to preload the xcontrol before using it to reduce the launch time.
Best regards.
Maxime R.
CLA - Certified LabVIEW Architect / Architecte LabVIEW Certifié
CTA - Certified TestStand Architect / Architecte TestStand Certifié
11-12-2008 12:47 PM
I feel we are not going to convince you that is a bug.
If the PSE for LabVIEW agrees with what you have said then there is a need to document this behaviour, so we should at LEAST get a "Documentation CAR"* so we can track when this "expected behaviour" will be documented.
Please post the CAR number so I can track it.
Thank you,
Ben
* Documentation CAR = Corrective Action Report to report and track short-coming in the documentaion, help files etc.
11-12-2008 02:08 PM
MaximeR wrote:
Hello,
You can remark that when the VI was load one time and that you don't close LabVIEW, you can reduce the delay because the Xcontrol is already in memory. But you need to keep a delay due to the redrawing of the Xcontrol. When you use a lot of Xcontrol or a big one, it's better to preload the xcontrol before using it to reduce the launch time.
Best regards.
OK enlighten me, how to do such a thing for an executable. Why can't the owning VI wait on the XControls?
Ton
PS if you are into debugging XControls contact NI Netherlands for the code on SRQ 682340