jives

MedAustron (http://medaustron.com) is building, commissioning and operating a state-of-the art ion-beam centre for tumour therapy and medical/physics research in Wiener Neustadt, Austria (close to Vienna). The technical design and construction of the particle accelerator has been done in collaboration with the European Organization for Nuclear Research CERN (http://cern.ch) in Geneva. For our technical team for the implementation and operation of the MedAustron accelerator we are looking for a LabVIEW Developer. For more details, please refer to the job description [1]. For technical questions, you can contact me via PM. For other (administrative) questions, please use the contact mentioned in the job description. In any case, we are looking forward to your application. [1] https://www.medaustron.at/wp-content/uploads/2015/01/20150116_Lab-View-Developer.pdf

I am currently working on a program to control data acquisition on a PXIe-6363 with tight timings. I need continuous sampling with a start and stop trigger, which I managed to get by using a reference trigger and by re-arming the task in software once it's done (i.e. if DAQmx Is Task Done returns True, I call DAQmx Stop Task and DAQmx Start Task in one go). Since the re-arming may take a while (easily tens of milliseconds) and I may only have 200ms before the next start trigger, I'd like to check for this issue by informing an external system that my application has successfully re-started/re-armed the trigger and is ready to go (the external system is kind of a watchdog). My problem now is that I don't know if the DAQmx Start/Stop Task VIs actually wait until the hardware is really ready (i.e. wait for the hardware to acknowledge), or just issue the command to the hardware and return immediately. I'd also like to monitor the state the task is in (with DAQmx Is Task Done), but again I don't know if that just queries some local state or if this VI actually checks if the hardware has finished starting the task (arming triggers, ...). I've read through all forum posts and DAQmx examples I could find, and the C reference, but couldn't find anything helpful. In short: Could I end up in a situation where I call DAQmx Start and then DAQmx Is Task Done and it returns False, but my hardware is actually not yet armed and ready? Do these VIs actually wait for the hardware to acknowledge the new state, or do they operate on some local state machine?

Got it now We don't use the LV VCS integration feature, so the checkout/checkin procedure is done by us manually via command line/TortoiseSVN. Before we check-in, we use the "Save all" feature in the Project Explorer (at which point SVN recogizes that the VIs have been changed) and only then commit the whole working copy and select all affected VIs. Unfortunately I didn't have the chance to check our SVN changes yet, but once I've done this I'll report back here!

Thanks for the extensive reply! Ad 2 and 3: I'll check as soon as I'm back at work, but it is highly unlikely that we had crosslinking between C: and R:, because R: did not exist before step 3 in my list. We just switched because we were forced to by our IT handling the VMs. Ad 3: It may be that the working copy was located in different locations on different machines, but I am quite certain that it never left the C: drive Ad 5: Definitely true! At least one VI was loaded from another location, and I am sure the first one was "find_buffer.vi" of the NI-Motion module, which we have in our working copy and which is also included in <instrlib>. I can try to reconstruct which VIs were affected here. Ad 6: I committed all files that where changed in the working copy, including the files that triggered the warning and the lvlib they belong to. This is also where we ended up with absolute paths in the lvlib. I am not sure what you mean by I checked the files out manually using TortoiseSVN in step 3, and committed them back in step 6 after LV had updated them. Just to make sure that my memory isn't failing me here I'll try and check all of the above once I'm back at work though.

I think what happened was roughly as follows (maybe flintstone could correct me if I'm wrong) Save files on the local drive C: in SVN working copy. Commit to SVN. Delete working copy on local drive C: and checkout on network drive R: Open project 1 (using X.lvlib) from R: and work without any issues for any of the relative paths in X.lvlib Open project 2 (using X.lvlib) from R: while project 1 is loaded into memory and get the "loaded VIs from different path" popup for X.lvlib:A.vi and X.lvlib:B.vi Save and commit project 2. Update working copy containing project 2 on another machine. Path for X.lvlib:A.vi is now absolute, while path for X.lvlib:B.vi is relative (both files are actually located under "R:MyLibA.vi" and "R:MyLibB.vi") The popup from step 5 seems a bit suspicious (X.vilib should already be loaded into memory completely), but maybe someone had the VIs in a different location before. However, step 7 is very unexpected, because I'd expect all VIs in X.lvlib to be saved with either relative or abolute paths (or at least theVIs indicated by the popup).

I am the ominous colleague who checked in the revision that "broke" our VIs A while ago we were forced to switch our checkout directory to a network drive. The actual switch went smoothly, and we did not see any of these path issues until later. I have only one copy of our code, and this copy is always located on the network drive on my VM. I never open code that is located somewhere else if I have another project open at the same time. However, I definitley had the VI in question loaded into memory, because I had another project open at the same time, and this project uses the same lvlib. I did get a dialogue that a VI was loaded from a different location, but this was a different VI (the NI-Motion find_buffer.vi). This VI is actually a part of <instrlib> as far as I know as well as located in our SVN as a local copy (because we had LV installations where this VI was located in a different path in <instrlib>). I'd say we have a combination of all of the possible causes mentioned above - just not for the VI in question (TIME_msecTimerTimeout.vi). Is it possible that other VIs inside an lvlib get affected LV changes a path from relative to absolute?

EBG MedAustron is building and will later on operate a state-of-the art ion-beam centre for tumour therapy and medical/physics research in Wiener Neustadt, Austria. The technical design and construction of the particle accelerator is made in collaboration with the European Organization for Nuclear Research (CERN http://cern.ch) in Geneva. In our dynamic team for the implementation of the MedAustron accelerator we are searching for an Embedded System Engineer. For more details, please refer to the job description [1]. For technical questions, you can contact me via PM. For other (administrative) questions, please use the contact mentioned in the job description. In any case, we are looking forward to your application. [1] http://www.stepstone...9439-popup.html

Yep, got the confirmation on the NI forums that that should do the trick. Thanks!

I have an M-series DAQ module (PXI-6221, may be replaced by a PXIe-6231), on which all DIO pins are used for static/general DIO purposes. Now I would like to connect encoder signals from a PXI-7344 module via the RTSI lines to the counter(s) of the PXI-6221 in addition. So the specific pins would be pins 3, 37, 45 (counter 0) and pins 41, 42, 46 (counter 1) which I would like to route to the RTSI lines for the counters only, while at the same time using the same pins for general DIO purposes on the front panel connector. I tired to use the Export Signal and DAQmx Dis/Connect Terminals VIs, but I am not sure how to (re)route the counter inputs to the RTSI lines and route the front panel connector pins to the general DIO circuits. Is what I am trying to do even possible with the hardware I'm using? Btw, this is a cross post with the NI forums (http://forums.ni.com/t5/Multifunction-DAQ/Simultaneous-Counter-and-DIO/td-p/1703044), apologies for that.

Thanks for your reply and for reading my whole monstrous post You are completely correct - I have classes (the framework calls them components) which instantiate other classes (I call them modules). I do that statically, by just dragging the class (or class control) into my VI, and I do the same with the class's public methods. Your suggestion to prefix the class's filenames is a good one, thanks! I've been trying to avoid that for the sake of standardization, but after spending hours trying to find the right setup for the AppBuilder, I think I'll just use your idea Dynamic loading is not needed in my case, and although fixing the problem it would just add another (unnecessary) layer of complexity to my code.

Hi folks, I am having a bit of a problem with one of my applications, and I just wanted to make sure that it is not stupid packaging and/or directory hierarchy issue. I have a LVOOP framework running on a RT target, which dynamically loads LV classes called components. Components inherit from the component class inside the framework and are built as source distributions. The framework looks for those components in a directory on the RT target and loads them during runtime. Everything works fine when I use simple classes. Now I have a couple of components (they represent real hardware) which in reality consist of a collection of hardware "modules", plus some component specific stuff. These modules are the same for every component which uses them, but not every component may use all modules. Because (in general) these modules don't share common properties or functionality, I implemented them as independent classes, which are instantiated inside my components. That was the easy part The problem now is that I am using the same naming convention and directory structure for all classes, which looks like this /Components/ /Components/Component1/ /Components/Component1/Comp1.lvclass /Components/Component1/Private Data.ctl /Components/Component1/Private Data Ref.ctl /Components/Component1/Class Initialize.vi /Components/Component1/... /Components/Shared/ /Components/Shared/Module1/ /Components/Shared/Module1/Mod1.lvclass /Components/Shared/Module1/Private Data.ctl /Components/Shared/Module1/Private Data Ref.ctl /Components/Shared/Module1/Class Initialize.vi /Components/Shared/Module1/... /Components/Shared/Module2/ /Components/Shared/Module2/Mod2.lvclass /Components/Shared/Module2/Private Data.ctl /Components/Shared/Module2/Private Data Ref.ctl /Components/Shared/Module2/Class Initialize.vi /Components/Shared/Module2/... [/CODE] and I would like to mirror it in my source distributions. If i now go ahead and build the source distribution of Component1, the directory structure gets flattened, which leads to following problems: 1. Filename conflicts for Component1 and all modules. The builder tries to correct this by creating subfolders and moving the conflicted files into those, but the framework then complains about not being able to load Comp1.lvclass (and throws a LV error code 1498). I assume thats because my component or module does not know about the new subfolders which were created during the build and is looking for VIs in the wrong place. 2. This also creates a copy of all files of all modules used by a certain component in its folder, even if they are shared between components (not that big of an issue I think). I tried to correct these problems by configuring the build in a way that the folder structure on disk is maintained in the source distribution. [i]This actually works[/i], as long one does not use VIs from vi.lib or user.lib somewhere in the components or modules. If one does, they get copied into their own nested places. The _complete_ directory structure in the NI folder then mirrored, and the framework will again not able to load the component(s), because it expects them to be in a certain (fixed) subfolder - not mentioning the subfolder mess which is created in the process. I also tried to build separate source distributions for the component and each of the modules - which again does not work as expected and leads to the framework throwing a 1498 error code while trying to dynamically load the component. I am not sure why this happens, and I even tried loading the module dynamically in my component. My question now is: Am I doing something wrong while building the source distributions? I have a feeling that this may just be a simple problem of just not using the AppBuilder in the right way (wrong project scope, wrong options in the build, etc.). Is there a different way of packaging my modules (llb, etc.)? Or is this a more complex issue with what I am trying to do or even how the framework loads its components? Any input on this would be highly appreciated

Thank you all for your inputs, they were all very helpful (especially normandinfs post, because something like that was what I was looking for)

Hello! Is there any way to automatically disable or enable specific LV code when building an application? Maybe with a conditional disable structure, or something like that. This would come in very handy, for example when using a relative path which changes when running code as an application or in the LV development environment. Or one could hide debug output which is useful in the LV environment, but not in a standalone application. Any help is greatly appreciated!

Thanks for all your replies! QUOTE (crelf @ Aug 29 2008, 06:33 PM) I'm not sure what the difference is - since the application does not need any user input and does no presentation of data, I don't really "need" a Front Panel QUOTE (Yair @ Aug 30 2008, 07:58 PM) You need to have at least one front panel in your application, or it will be shut down automatically, but as Ben suggested, you can set its state to Hidden, which accomplishes the same goal. Additionally, if you're running Windows, you can convert the executable to a Windows service (which does not have a window) and it will run even if you don't log into the machine. You should be able to find the details on NI's site. Thanks for the tip, I'll see what I can find. Only to check if I understood that correctly: If I convert my application to a service, the FP will automatically be disabled/hidden?

Hi everyone! Is there a way to completely disable the front panel in an application? The idea here is to create a lightweight and robust VI server program which can easily run as a service routine. For all interactions with the user, a client application will log in to the server and displays the current status, recorded data and provide means to control the server VI using data sockets (or something like it). So far I have found some ideas all over the internet, but most of them are some kind of workaround like setting the transparency of the front panel to 100%, or loading a reference to the front panel into memory and close it afterwards. Since we are trying to build very robust and lightweight applications, we are kind of suspicious regarding these methods. Any input is very appreciated