jgcode

Hi Athalia As long as all functions and structures etc... used are available in 7.x then you should be able to. I know you can't save for 7.x using 8.2.1, I don't know which is the first lower version that will work but 8.0 should be fine (maybe someone can confirm which it is?). You will have to open the VI in LabVIEW 2009 first. Then select File>>Save for Previous Version... Then save it down to e.g. LabVIEW 8.0. Then you will have to open the new VI in e.g. LabVIEW 8.0 Then select File>>Save for Previous Version... again to 7.x

I am pretty sure there is a network queue in the LAVA CR, or that someone posted that might be work a look too..

Well... ...try it!!

Depending on what you are doing... one way would be to create a run time menu and assign shortcuts through there. See here for a start on creating a run time menu.

Congratulations mate, great job

No probs!

Like Ton said, M series is straight up a basic DAQ card You can get PCI with FPGA but it is R series. The code you write for the FPGA will run on the FPGA, meaning it will be deterministic. There is no OS on the FGPA, the code is burned onto the chip. I am pretty sure you will only need LabVIEW + the FGPA module to program the R Series card. Depending on you specifications requirements you may find using a target with a RTOS is more flexible. E.g cFP or cRIO (which has FPGA as well). I.e you cannot do floating point maths on FGPA. You can now do fixed point which is cool tho. You would use the LabVIEW + the Real Time module to program the RTOS. Well written code will be deterministic. E.g. A standard PC running Windows OS is not a real time target. If you wanted to turn a PC into a RT target see here and here to check if your PC meets the requirements.

Cheers I tried again and it worked so maybe it was busy last night? This shows all the presentations - thanks for the link! https://lumen.ni.com/nicif/us/niwkswdevtech/content.xhtml

Thanks Jim much appreciate - and you guys as JKI inspired this one - so thank you too! You will be happy to know I had to take out the UTF because I could create a dist with it in (I have to follow this up to check whether the error is a bug or not). Anyways, I think VI Tester API will fit in there quite nicely.

Thats Darren that makes sense. I am heading over there now...

Hello AQ (thanks for putting the hooks in 2009 by the way ) Yes it does! and no it doesn't. I didn't add support, but running the scripts tidies up the BD Labels but its not switching the connector pane for the arrays (obviously where its erroring out in the code). Due to the style I use, I always have error in/out. But thats a great point and something I will add for the next release. I guess I should just check for error in / out terminals to determine type of template?? Is there a better way? Is that aa flag that is available somewhere? Are you able to comment on how you would support this? Cheers for the feedback! JG

I had to elaborate on this one in cross-post... Hi tst I will try to explain further and I will use JKI's VI Tester package as an example... One of the component of VI Tester gets install in the Project Folder (aka Tools Pluign Menu) of LabVIEW. I.e. <LabVIEW>\project\VI Tester folder contains VI Tester.txt, VI Tester.llb and New folder (containing NewTestCase.llb & NewTestSuite.llb) VI Tester.txt contains the following text: VI Tester Menu Launch__VI Tester Menu Launch.vi New Causing the Tools RTM looks as follows: Therefore, LabVIEW, working with a plugin, is able to be pointed to a specific VI in an LLB through the text file. Distributing code for a tool in an LLB is a nice way to include all dependencies for the developer. Now with respect to Quick Drop - it would be great if I could distribute a LLB file and a txt file and Quick Drop can read the text file and know what top level VI to point to in the LLB should that shortcut get called. So my question is - Is this possible at the moment?

Well, heres cheers to LAVA

[Cross posted to ni.com] Hello I was wondering if it is possible to create a Quick Drop plugin with an LLB type structure. Similar to what you can do with the menu items - have a text file that points to the VI to run. (I hope that makes sense) This would be cool for distributing code. Look forward to hearing if this is possible. Cheers JG

Hi ASTDan The link is coming back broken. Cheers JG

It was just in case the boss was reading it But I have to say; all these forums help me with my work as well, I don't think I would be as productive, or inspired, without them. But I have to be careful, I could easily chew through an hour without even noticing!

Hey Jim thanks for posting - I am checking it out now over lunch. May I ask what project SmokeCal is about? The name sounds very Bondish

Here is a visual comparison of the scripting. It may not be everyone's cup of tea but it may serve as a good starting point (or may not!! ) Original Simple Write vs New Simple Write Original Simple Read vs New Simple Read Original Array Write vs New Array Write Original Array Read vs New Array Read Original MultiDim Write vs New MultiDim Write Original MultiDim Read vs New MultiDim Read This release ties up my previous posts of the individual VIs onto a single package. LVOOP Custom User Scripting For New Simple Accessor VI LVOOP Custom User Scripting For New Array Element Accessor VI LVOOP Custom User Scripting For New MultiDim Array Element Accessor VI Of course none of this changes the functionality much, so it's a nice to do. It's just that it's my preferred style. And if I now don't have to do any work to get this effect than that is great! Enjoy! JG

Name: LVOOP Custom User Scripting Submitter: jgcode Submitted: 16 Nov 2009 File Updated: 03 Jan 2011 Category: *Uncertified* LabVIEW Version: 2009 License Type: BSD (Most common) LVOOP Custom User Scripting v1.1.1-1 Copyright © 2009, Jonathon Green; JGCODE All rights reserved. Author: Jonathon Green LAVA Name: jgcode Contact Info: Contact via PM on lavag.org LabVIEW Versions: LabVIEW 2009 Dependencies: No Dependencies Description: Contains Custom User Scripting Hook VIs which are called at the end of their respective scripting processes e.g. New>>VI for Data Member Access... New scripting includes: All - BD control labels to left - BD indicators labels to right - BD controls moved closer to case structure's left hand side border after label repositioned - Case structure expanded downwards and free label placed under error wire with default "Comment" - FP controls (excluding owning class or error in) labels bolded to match required parameter on connector pane Array and MultiDim Array Only - Index/Indices control moved outside case structure inline with other controls - Data Member control and Index/Indices control switched on connector pane - Index/Indices control set as required parameter on connector pane - FP reflects new connector pane order Other features includes: - Default save name for Write Method changed from "Write " to "set" - Default save name for Read Method = "Read " to "get" Hooks are installed in the (LabVIEW 2009)\resource\Framework\Providers\LVClassLibrary\NewAccessors directory This package installs the following hooks:- Scalar Data Member - BaseAccessorScripter\Custom User Scripting For New Simple Accessor VI.vi 1D Array Data Member - ArrayElementScripter\Custom User Scripting For New Array Element Accessor VI.vi 2D+ Array Data Member - MultiDimArrElemScripter\Custom User Scripting For New MultiDim Array Element Accessor VI.vi See here for more information All existing hooks will first be moved to a persistant folder (\addons\_JGCODE Toolkits\lvoop custom user scripting\NewAccessors Original). The packaged hooks will then be installed. If the packaged scripting does not match your style then they may server as a useful example. Installation and instructions: Install the package using VIPM. At unistall, the packaged hooks will be unistalled and replaced by the original hooks. Examples: Open Examples\Test.lvclass Right click on the Test.lvclass and select New>>VI for Data Member Access... Select a read and write template for Simple, Array and MultiDim Array . Inspect the FP and BD of the new VIs created to see the additional scripting. Save the Simple write method to see the new default save name of "setSimple.vi". Save the Simple read method to see the new default save name of "getSimple.vi". Known Issues: All - If a template name already exists LabVIEW will change it to a default. This will usually occur for arrays where the data member name is not used, but rather the element name of an array. Array (Read/Write) - Comment is sitting on Index Control's wire Read - Index control not in line with Index Array function MultiDim Array (Write) Indicies control not in line with Index Array function Acknowledgements: Stephen Mercer (AQ) OpenG ICON Technologies François Normandin Version History (Changelist): 1.1.1-1 2009 12 22 [New] Renamed packaged, designated old package as conflict [New] Updated .zip name to include LabVEIW Version (LAVA CR Certified requirement). [New] Dependencies included in package [Fix] Removed CLSUIP_LocalizedStrings.vi so as not to distribute NI VIs (LAVA CR Certified requirement). [Fix] Changed nameing convention to retain capitalisation. 1.1-1 2009 11 27 [New] Added support for when "Include Error Handling Terminals" is unselected [New] Default save names included. Write: set; Read: get (where is the Data Member Name in camel notation) [Fix] VIPC file now does not contain packages, it is a list only [Fix] Removed Quick Drop dependency 1.0-2 2009 11 17 [New] Added VIPC file for dependencies 1.0-1 2009 11 17 [New] Initial release of the code (LabVIEW 2009). License: BSD Support: If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the LVOOP Custom User Scripting support page. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Click here to download this file

Ton is absolutely correct Attached is an example. Run it as before. The principle will be the same for your application - your app must hold the persistent data, then the menu is prepared on the filter event. The menu does not hold the data. Custom Run Time Menu Control.zip [LabVIEW8.6]

Hi Spaghetti Love your avatar by the way!! Yes you will need to use those functions. Attached is an example. Run main.vi and then repeately select Custom Item from the menu to toggle its checked property. You can edit the menu by selecting Edit >> Run-Time Menu (when the VI is not running of course). Custom Run Time Menu.zip [LabVIEW8.6]

Hi Germi It not a good idea to change vi.lib VIs and leave them in the same location. Anyways, I did a search for Reflection Point.vi in LabVIEW 2009 and all that got returned was an MGI VI named Bezier Reflection Point.vi. Are you sure the name is correct? Cheers JG

I should also mention if everything goes well you should see this

Hi Jim I have saved it back to 8.6 and tidied up the release a little. I had to take out the Unit Test Framework VIs for now - I will have another look tomorrow after work. I have included a VI with the disabled case at the moment so you all you have to do is just paste it in. I will create a OpenG package for this next in the next release as well. Hope you like it! Cheers JG UTF(86).vi [LabVIEW8.6]