_Y_

Thank you for the replies! asbo, yes, the program is supposed to run-time license; yes, the plug-in VIs are not supposed to be incorporated in the EXE. I did not post the error codes intentionally. There was a variety of codes of very general scope. To my understanding, all pointed to missed linkage to sub-VI. JamesMc86, yes, I believe some dependencies are missed (inly when called by EXE). However, the VIs are assembled in a Source Distribution. Meanwhile I continue struggling with the issue using the great “guess-try-error” method. For some obscure reason I prefer “understand-create-enjoy” (actually this is why have I asked about basic principles). Anyhow the “guess-try-error” gave some result. Some plug-in VIs work if I include vi.lib in the Source Distribution. It is obviously a bad practice but any progress is better than none. So I try to split my question: 1. What happens if the EXE and the dynamically linked Source Distribution contain copies of the same files and/or same classes? How the engine treats such redundancy? 2. If using Source Distribution is unavoidable, the reasonable way would be creating a separate Source Distribution build for each plug-in. However, this means enormous redundancy. How do multiple Source Distribution structures interact with each other if called by the same EXE?

Shortly: We desperately need a good hint on principles describing how an Application (EXE) build interacts with Source Distribution build(s). Descriptions found in ni.com and generally in Internet mostly advise “use Source Distribution” not saying “why”. It works perfectly with simple test projects but is not sufficient for our real needs. Please advice where the general principles can be read. Details: There is a framework code (GOOP4 that means that all problems should be the same with build-in LVOOP). The framework dynamically invokes VIs. The dynamically invoked code also has OOP architecture. A perfect architecture would be creating the framework EXE and keep the dynamically invoked code as loose VIs in HD. However, it does not work. The framework EXE claims that the VIs are broken (while they are not). The common advice is deploying the VIs as a Source Distribution. However, this does not work too. If controlled with a property node “Execution state”, such a VI does not show the result “Bad” but an attempt to start it results in an error. I guess that the problem could be in the fact that some classes are used both the framework (the EXE file) and in the Source Distribution. However, I have no idea how these two builds interact with each other deciding which copy should be used. Unfortunately, error numbers that are shown are poorly described. So far we could guess only that the problem is in finding some sub-VIs. Thank you for reading to the end

asbo, thanks for reply. I should wait for few days. May be some one already has an info about it. It is in LV2011, nothing too new:)

I encountered a strange behaviour of Quit LabVIEW node. If the node is placed in a VI that is started by Start Asynchronous Call, LabVIEW environment is not closed. Only the asynchronous process is stopped (but the VI is not unloaded). The same happens if EXE file is built and started. Such a behaviour looks strange for me. Could someone explain what is wrong in my perception of Quit LabVIEW node? A small project is attached. LabVIEW 2011 QuitLabVIEWnodeQ.zip

Thank you. I do not understand too. As a fact, it was very difficult to recall even simple steps in VB6; do not mention about its internnal behaviour. I am not so terribly happy with the solution. It obviously adds lot of work at the development step. But ... this solution is better than no solution

Actually, I solved the problem. Found a way around. Quite around But first: If no ActiveX is involved, the Invoke Nodes work asynchronouusly without any problem. This includes parallel cals of a reentrant sub-VI. Now the solution: The program is split in separate programs communicating with each other. For this test, I used Shared Variables but this is only a test. Each part/program contains only one instance of the ActiveX and performs all tasks related to this instance. Of course, such a solution does not solve the problem at all. Calls to the ActiveX from independently started VI-s wait for each other. Now - the trick: Each part is compailed in an independant EXE file. The EXE-s can be started simultaneously but they are in different "virtual spaces". So, instances of the ActiveX have no idea about each other and the problem is gone. Now I shall find how to start several copies of the same EXE program (by default, the LabVIEW compiled EXE allows only one instance). But this is a minor question. At at least, several copies can be started applying Ctl-C Ctl-V to the ready EXE file

Sorry, I probably did not write clearly. The ActiveX is not my. It is a "black box" for me. To my knowledge, it is written in C++. But I have it "as is"; i.e. an OCX file compiled and registered in Windows. So, converting it to DLL is out of question. The simple VB code is my but it was created only for these tests. The reason for the difference is simple: even after 10 years or so I can recall programming in VB6 but I newer used C++ I did not change anything in settings when created the simplest ActiveX in VB6 but, outside of LabVIEW, its instances work asynchronously. Seems the default model is MTA. As I understand, you ask about the last example. The ActiveX calling Invoke Node does not pause the whole program. If I do not use Invoke Node in the bottom structure, there would not be any delay.

Thank you, Saverio. Indeed, the thread points that the ActiveX is executed in UI thread. Unforttunately, this is not a new or helpfull information. I cannot wrap the ActiveX inside a DLL because the actual ActiveX is a "third-party product". The ActiveX(-es) that are considered in my examples are created only for these tests. So, I need to find some trick around this LabVIEW limitation. The limitation certainly belongs to LabVIEW. A simple non-LabVIEW program (I did it with "good-old" VB6) shows that instances of the same ActiveX work asynchronously even if their UI-s are used.

Phillip Brooks, thank you for the link. Unfortunately, that discussion solves invocation of an ActiveX incorporated in a DLL. At least, I understand it in such a way. To my knowledge, DLL-s are called using Call Library Function Node that is configurable and can be set for execution in a non-UI thread. I call the ActiveX directly; i.e. using its reference. In this case the Invoke Node is used (that is not configurable). To test such a possibility, I tried to call ActiveX using Call Library Function Node (pointing to the OCX file instead of a DLL) but without any success. Seems that the node can see internal function of the ActiveX but the VI is still broken reporting that the function does not exist. Probably, an OCX file cannot be accessed using Call Library Function Node.

Hello all, I encountered quite a puzzling problem. May be some of you know a solution or some trick. Shortly As a rule, Invoke Node works asynchronously. If two Invoke Nodes are called in different loops, threads, or processes, they are executed independently. But it does not happen if they are used to execute some function of an ActiveX (OCX file). I need to invoke the same function of an ActiveX asynchronously. Of course, I create two instances of the ActiveX but, the Invoke Node that is called first blocks execution of the second; i.e. two invocations are executed consequently. I need a “pure-asynchronous” execution but could not find any solution. Some interesting experiments Experiment 1. I created an ActiveX containing only one function. The function simply waits for a number of milliseconds than returns a String value. If called from a non-LabVIEW program, two instances of the ActiveX work asynchronously without any problem. But it is not so in LabVIEW Experiment 2. To do a “pure” experiment, I created two independent ActiveX-es. Both have the same function but even names are different. This block diagram shows the same test but with two different ActiveX-es (the same code as in Experiment 1 but the ActiveX holders point to two different ActiveX-es): Two Invoke Nodes are not executed asynchronously. They wait for each other. Experiment 3. This experiment is probably most puzzling. I created a sub-VI that do exactly the same – waits for a number of seconds. Of course, if such a sub-VI is reentrant, its instances can be invoked asynchronously. Now I tested what happens at parallel use of Invoke Node on instance of the ActiveX and on the sub-VI: Now - the show! If the sub-VI is invoked first (bottom structure), the ActiveX is invoked asynchronously. But! If the ActiveX is invoked first, invocation of the sub-VI waits! Thanks in advance for all ideas.

Ops! The life is full of small disasters Is any way around this limitation? The main motivation of using the CANopen library is the good integration with NI CAN Series 2 cards.

I am slowly progressing through the problem. Now the question can be re-formulated (sorry for this iterative way of questioning). As I understand (now ) The frame with arbID=0 is normally sent by "main" unit in the CAN network in order to control states of other units. The CANopen library provides a VI to send such kind of frames: However, I cannot find a way to receive this frame if the frame is sent by an external unit. My LabVIEW program is not the "main" unit of the network. So, it has to receive the frame and act accordingly. Could you advice please? May be I misunderstand some concept?

CAN protocol does. The equpment sends this frame and the frame carries the data. However, I am not sure that CANopen can receive such a frame. This is actually my question: How can I use CANopen library to receive the CAN frame with arbID=0?

Thank you for the answers. The problems above are solved in some way but struggling with CANopen is going on. New questrion: How can I listen for a frame having ID = 0? If I set COB ID to 0, the ID used by the CAN frame is assembled on base of the combination of two CANopen parameters: PDO type and node ID. I could not find any combination of these parameters that could give ID=0 in the CAN frame. Thank you.

Hello, I am trying to use CANopen LabVIEW library to replace conventional CAN-communicating code. As I understand, this library allows moving the load from computer to internal processor of the NI CAN card Series 2. Unfortunately, help/examples of the library are not sufficient for newcomers. 1) The main question is: How can Synchronous PDOs be implemented? The program must get a sync message from an external device and reply with an information-containing frame. I created a simplified code that does the work but does not appear as an efficient solution. This is the diagram. The VI is attached (LabVIEW 2009). Every time when the program gets a frame with ID=x80, it replies with the information-carrying frame (ID=x123). However, the implementation looks unreasonable. Data feed to the CANopen PDO Write.vi are rarely changed but they are read from data control each time. Is it only the way to implement such behaviour? Besides, I have some additional questions: 2) What is the role for the NodeID? I have tried several values but did not get any difference. 3) What is the role for PDO type? It can take one of 8 values grouped by 4+4. As I understand, the groups differ by the direction (read or write). However, changing the PDO type within the group does not have any effect. 4) Is there a good description of this library? My experiments with Google have not provided any good result. Thank you CanOpenSync.vi

I do not have a direct answer. This is a way around. It works if you need to create Excel plots/charts from a LV program. First, manually create an Excel templ containing a macros in VB. The macros should take some raw data and create all fancy staff (images, plots, barcharts). The LV program should: 1. ceate a new Excel document from this template; 2. export only basic data from LV to the Excel document; 3. run the macros. IMHO this is a faster way because debugging of a pure LV program could be a nightmare. Each run of the LV program will end with opening the Excel document, observing a crasy result, and guessing the reason. Another advantage: less problems when working with different generations of Excel. Disadvantage: the LV and Excel plots wold not be visually identical.

Thank you for the idea. However, in my case, the problem was more complicated. Seems, Find->Callers do search the diagram disable structures. At least, it pretends to do so. So far as the project could not find the deleted members, corresponding calls were automatically replaced in the diagrams with "lovely" grey-question-mark-nodes. Find->Callers does not search for them. As these nodes were in disabled cases no error appeared. I had to search all diagram disable structures in the project (automatically), open each disabled case (manually), and look for these question-mark-nodes (visually). PS: More tests have shown that the problem does not appear every time when a call to deleted vi is hidden in a diagram disable structure.

I encountered a problem when tried to clean an overgrown Project in LV 8.6.1. Removal of project members does not usually cause any problem. In some cases the removed members are not forgotten. They simply go to Dependencies. This is justified if remaining members call the removed vi-s. However, in some cases, members of Dependencies have no callers (the pop-up menu Find->Callers results in No items were found.). If I delete the corresponding files, conflict signs are displayed. The project is fully functional in all cases. I tried to remove the corresponding line(s) manually from the lvproj file (that is an XML file). The line(s) reappear if the project is opened and saved again. It seems there is something like "hidden callers" in the project. Does anyone encountered and solved the problem? If so, please advice how to remove such unused dependencies. Thank you.