Jump to content

mzu

Members
  • Posts

    55
  • Joined

  • Last visited

Posts posted by mzu

  1. AQ, Thank you for the reply,

    enabling the highlighting tool is not a problem, and if nothing else works I will resort to that. If we talk probe scripting then I can script some code inside (and outside) of each of B.vi which will pass the unique ID to each of the B.vis. But those solutions look like hacks and workarounds to me.

     

    What I am actually looking at is the kind of functionality that the breakpoint provides. I mean, let us modify the code for B.vi as follows:

    post-2886-0-74045100-1369988130_thumb.pn

    Now it will stop when B.vi is called the second time. I go to the "stack trace" menu on the top:

    post-2886-0-59743600-1369988453_thumb.pn

     

    and the LabVIEW highlights the exact node out of 3 B.vi nodes where the breakpoint occured: the second one:

    post-2886-0-91423600-1369988626.png

     

    How is it done inside of the LabVIEW, and is there any easy scripting way to get an access to this functionality?

  2. I am working on a tiny debugging tool. Say, we have a 2 vis, A.vi and B.vi. A.vi calls B.vi in multiple places on the BD. B.vi is being executed now. I would like to get the reference to the node on the block diagram of A.vi of a particular B.vi being executed right now (It may be paused, or just running). Same way as we  get clickable "stack trace" drop-down list on a breakpoint. How can I accomplish it?

     

    A.vi BD:

    post-2886-0-87864300-1369783596.png

     

    1. If B.vi is reentrant, I could have used clone #. But if B.vi is not reentrant?

    2. I can easily get an array of nodes of type "subVI" on A.vi BD. But the node does not have any property to show it's state (reserved, running, idle, bad etc).

    3. Each VIRef of each subVI node has different numerical value. However, I was not able to find a VI property that would give me the distinction between a running VI and a reserved one.

    4. I enabled supersecretprivate key in the ini file, but still no methods/properties I can use.

  3. it, it is kind of annoying though.

    That is what I am talking about. The trick with property node -> Selected sort of works works but I there might be some hidden problems. At least none of the XControls that ship with LabVIEW do that.

  4. When (in edit mode) you click on the border of a regular control it becomes selected.Not so for all XControls I've seen or created so far. The only way I found to mimic the behavior is to use Control refnum from the container state cluster and set "selected" (Scripting enabled) property to true.

    Questions:

    1. Is it safe to do so, as I recollect there some synchronization related limitations on what you can do with this refnum.

    2. Do I really have to enable scripting; am I missing some much easier way to do it?

  5. I'm sorry to be the bearer of bad news, but it doesn't appear this feature will make it into the 2011 version. There seems to be too much disconnect between the two pieces to be sure of a quality integration at this point in the release cycle. It will be a high priority going forward from here. Thank you for bringing this to our attention and I am very sorry that it's not working yet.

    Thank you for an answer... Will look for the next release. Back to designing workarounds ...

    I understand that it is impossble to make it work properly now for 2011 release, but is it posible to make it so that LabVIEW 2011 spits out a meaningful error, instead of "VI failed to comiple"? And does not crash afterwards?

  6. This is the way simulation subsystems work - they are "macroed" inside the top simulation diagram, say this one:

    post-2886-0-20966200-1304361658_thumb.pn

    would be executed same way as top level simulation diagram and as a subsystem. So, ading this feature to LabVIEW would not be a big problem (but totally pointless).

    and yes, I would agree with you that a warning may be justified when the subVI is created out of 2 totally independent things - and this might be a good topic for idea xchange.

  7. Yes, if memory serves correctly, 8.2.1 was a massive upgrade for LVOOP rather than the standard minor fixes.

    Anyways, I have seen weird stuff with using it so I wouldn't recommend it (I was forced to by a client's license).

    My regular development platform is 2010SP1, but this time I am forced to use 8.2.1. due to client license.

    jgcode, were your problems stability related, performance related or ... ? Did you refer to 8.2 or 8.2.1 when you spoke about the problems?

  8. Starting new project for old LabVIEW (version 8.2.1). I recollect there were some problems with LVOOP in 8.2, some of them so severe, that it was suggested not to use it in 8.2? I tried googling it out - no luck. Can somebody kindly point me to the problems I might run into.

    So far I remember:

    - no dynamic dispatch recursion

    - no properties

    - no friends and community scope.

  9. Are using the "Base Package"?

    This particular implementation of Exponential fit was known to have problems when data falls below 0. Use http://zone.ni.com/reference/en-XX/help/lv/71/gmath/Levenberg_Marquardt/ instead.

    I am not a great fan of express VIs, but potentially you can use Curve Fitting.vi express VI. Both require something more then base package.

    An overkill for such a simple problem, but you can also use

  10. Here is a modification of silmaril's example to include the alternative to Run VI method I described earlier. In order to run it you have to download worker pool from Tomi Maila's blog: http://expressionflo...4/worker-pool/.

    class Incrementer inhertis from class Command. Everyhting works asynchronously with UI as expected. Once again Kudos to Tomi Maila for contributing this solution to the community and one more reason for all of us switch to LVOOP if you have not already ...

    Test_UILock_classes.zip

    post-2886-0-27487800-1298609555_thumb.jp

  11. Mads, thank you fro the find. I used RunVI method without realizing this.

    The only other reasonable alternative to using Run method I know is http://expressionflo...04/worker-pool/ It should not suffer from switching to UI exec subsystem

    But that one is more suited for running a set of identical "worker threads" that sizes with the size of task rather then launching a plugin.

  12. I have read about the possibility of using CINs, but... since they are not supported in LV2010, is there any equivalent method or way of doing what you were able to do with them?

    Like what? Since LV 8.2 callbacks are supported by DLLs.

    I suggest reading my favorite article on the topic: http://expressionflow.com/2007/05/19/external-code-in-labview-part2-comparison-between-shared-libraries-and-cins/. Parts 1 and part 3 are of some interest as well.

  13. thomasvd,

    let me restate what you've just said:

    You need to be able to update a dll, containing ActiveX object without restarting LabVIEW. Is this correct?

    If so, I would incapsulate all ActiveX calls into a new VI, loaded via VI Server. So, when your main program is done executing, it unloads a VI from memory, thus destroying all references to your dll.

  14. Ok. Turns out no user has ever asked to do that before, and since the Sim team wasn't aware of OO features and the OO team wasn't aware of Sim features, no one knew to proactively add the feature. So simulation diagrams do not support dynamic dispatching. I filed the CAR (#280810) so that it gets attention. I tagged the CAR for LV 2011, but because we are fairly late in the dev cycle for the release, it wouldn't surprise me if the fix has to wait for a future release.

    I'm sorry you got burned by this communication failure on our part.

    Wow, that was a fast reply! Thanks, Aristos, I will be waiting for a future release.

    I the meanwhile I will have to include control and simulation loop for each of the child classes.

  15. Been working on LV for 10 years, but I have no idea what "New simulation subsystem" means. Is this some module or toolkit addon? If so, which one?

    Simulation subsytem is a modular unit of simulation diagram, which can be excuted inside control and simulation loop, using "Control Design and Simulation Module", URL. It is graphical representation of dynamical systems. Some people use Mathworks Simulink for the purpose. (There was some patent dispute if my memory serves me well).

    I wanted to develop an LVOOP wrapper around the simulation diagram, so that I can delegate the simulation diagram development to my colleagues.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.