PiDi

Note: G Code Manager is now available at GitHub: https://github.com/veritechpl/gcm G Code Manager GCM is a tool that makes the properties of Project Items in Project Explorer window more accessible, removing unnecessary waiting times and modal windows. In runs in window next to the Project Explorer window and shows the items properties immediately after selecting new item in the explorer. GCM also allows you to create your own plugins to access those Project Items! Requirements The package was built in LabVIEW 2014, it should also run in LabVIEW 2015. How to start In the Project Explorer window click on the Tools menu, then select G Code Manager -> Run GCM… Download IMPORTANT NOTICE This tool was made using some internal LV APIs which are not fully tested and documented It is in very early stage when it comes to stability It may cause LV to crash! I strongly advise using source control - if you're not using one, do not even install this tool! (Above statements are really for your own good - I'm using this tool in my everyday work and I don't have any major issues. However, you might accidentaly clear your VI description or icon, or something like that, so be prepared for it by using source control like SVN or Git to revert the changes). Current Version Version 1.14.0.71 Download: veritech_labview_code_manager-1.14.0.71.vip - Added GCM settings screen - Added option to automatically open GCM with the project Older Versions Verstion 1.13.0.67 Download: veritech_labview_code_manager-1.13.0.68.vip - Interface cosmetics. Smaller window size - GCM remembers last selected plugin for the project item type - Dock button added, which makes GCM window always on front - Added support for build specifications: EXE, Installer, RT Exe, FPGA - Added VI Window Properties plugin (beta) - Added VI Execution Properties plugin (beta) Version 1.11.0.61 veritech_labview_code_manager-1.11.0.61.vip - Icon Editor: Added "Default Font Settings" which sets the font to 8 pt, centered, capitalized. - Fixed the synchronization issue between plugins (icon edited in Icon Editor was not updated in Basic Documentation). - Added new incoming events for plugins to better handle items selection/deselection and plugin activation/deactivation (see the attached documentation) Note: The plugins API was changed in this version. If you've made your plugin in previous versions, please refer to the updated documentation. If you have any problems, just contact me Documentation: GCM.pdf Version 1.10.0.58 veritech_labview_code_manager-1.10.0.58.vip - Added Icon Editor for VIs, which currently allows editing the icon text or clearing the icon completely Documentation: GCM.pdf Version 1.9.0.54 veritech_labview_code_manager-1.9.0.54.vip See this document for more information: GCM.pdf

Create "Source Distribution" Build Specification. Add the VI to Always Included in Source Files page. In Destinations page set Destination type to Directory. If you want to preserve the whole folders hierarhy, check the "Preserve disk hierarchy". In Additional Exclusions page you can include or exclude vi.lib, instr.lib and user.lib. Go to Preview page and see if your settings give you what you want.

If LabVIEW was already opened, it indeed doesn't pass new arguments from command line. One possible workaround is adding "allowmultipleinstances=True" line to labview.ini config file. Command line call to labview.exe will then open new LV instance each time, and consequently the arguments will be passed. However, as with every not well documented features: use allowmultipleinstances with caution (it can go weird if you open same code in more than one instance of LabVIEW).

According to this: http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/external_data_val_ref/#EDVR I've never used it, but I know at least one place where they're created: the DMA read/write to FPGA (http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqwrite/ and http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqwrite/). And then you can use them with Advanced Data Reference I/O from TDMS pallete. It seems like the code in the following picture might have some magical properties, like reducing the memory usage, or enabling really fast data transfers from DMA to files... Has anyone ever used this?

There is snapshot from November at https://web.archive.org/web/20151106102931/http://labviewwiki.org/Home , in case someone would need it.

@Shaun: Nice catch, I didn't though of refnums as containers - now it seems pretty obvious (I forgot I can drop control on the refnum to change its type). However, there are two problems with the code on your screen: 1. The "style" input of New VI Object is a mess. I want to provide Class Name and nothing else, so I'd have to somehow decide how to translate the Class Name to style. I can think of couple of ways to do it, all of which would probably require a lot of coding. 2. This only allows to create GObject references. This is quite OK, because that's what I need for now, but my method allows me to create any type of reference (like ProjectItem, or Panel).

I've got the workaround: 1. Create ClassSpecifierConstant on block diagram - this one has SetType method. 2. Change it to control. 3. Now that you have the control with desired type, replace old control. It's a bit more wiring than those three points, so I'm just attaching the project with this implementation. ChangeRefnumClass.zip

I have a refnum control on my Front Panel and I want to change its class. Easy (well, if you don't count four "wait-for-menu-open" moments in process) to do manually Problem: How can I do it programatically? This is as far as I got with this - I was sure there would be some property/method of LVObjectRefNum class to do it, but I was wrong: I've attached the project with this VI for the convenience ChangeRefnumClass.zip

Oh, yes you can: put breakpoint in <LabVIEW>\resource\Framework\Providers\LVClassLibrary\NewAccessors\BaseAccessorScripter\CreateBaseScripter.vi.

The only time I've seen it broken like that is when I broke it myself when playing with Custom User Scripting for accessors. This is just a shoot in the dark, but check your <LabVIEW>\resource\Framework\Providers\LVClassLibrary\NewAccessors\BaseAccessorScripter\Custom User Scripting For New Simple Accessor VI.vi - by default its BD is empty.

Hmm, machine epsilon on my computer is 2.22045E-16, so there is no way to do precise calculations with e-18... You can check the machine epsilon with constant from numeric pallete (or with attached snippet):

Doc, just for reference: IMO, it shows the volume of the drive containing your folder, so it works right. The fact that it is mounting point doesn't matter, because it still logically belongs to drive C.

There is absolutely no way to create the controller for something that does not respond to controller output. In your design the controller does not output to the plant - the plant is only generating square wave, it is all the controller "see" and there is nothing it can do about it, because there is no feedback from controller to plant.

Let's make some (very) basic troubleshooting: have you used Advanced Open with "enable asychronous?" = TRUE? And then used VIs from TDMS Advanced Asynchronous Pallete to read/write in all your processes?

Are you sure you're using right datatype for this array, i.e. U8/I8 instead of U32/I32? This makes huge difference in elements usage.

Simply use array control/indicator on main FPGA front panel and use Read/Write Control node on host side.

I'll add to this case: project currently contains ~3000 VIs and ~300 classes. The code, written in LV2013, is shared between PC and RT PXI target. We've separated compiled code when the project already contained significant amount of code. The reason for this was irritation whenever someone tried to commit some minor changes into SVN, but found out that this minor change triggered changes to half of the project hierarchy. It was especially problematic when 3 people was making some heavy developmement on different modules and LV decided that it should recompile some libraries that didn't even had any apparent connections to each other (well, I think there are few to none people in the world currently who fully understand the ways of LV compiler ;P ). So we've separated code. I don't have any solid metrics to it, but we've concluded that our commits became clearer and number of conflicts dropped (ok, there is one metric - number of "wtf is this VI that is marked changed? I swear I've never even known it existed" dropped drastically). Now for the most interesting thing: the effects on deployments and builds. We have absolutely no evidence or even feelings that separation has made anything worse. By this I mean the deployments to RT were just as buggy, unreliable and painful as before separation, but not more. I remember at some point we've even tried to reattach the code (of course, with whole cache clearing, recompilation, etc) to check whether it would help with deployments and it didn't help at all. As far as I remember, we've even reverted the repo to the point before separation and first thing we saw when tried to run the code on RT was "Deployment completed with errors" You're absolutely right about problems in versions before 2013. I know from my collegues that they tried it in 2011 or 2012 in smaller project and failed. Summing-up: code separation seems to be very convenient for the team developement (but as I said - I have no metrics, just the general overview of changes commited to repos and feelings in the team). The deployments and builds of code which is shared between different targets are just generally broken, they don't seem to be more broken with compiled code separation as of LV2013. The apparent deployments fix when reattaching the code is probably just due to some recompilation happening in the process and is not connected directly to this option.

Have you tried to clear cache (Tools-Advanced-Clear Compiled Object Cache)? This should help.

Thanks Mikael, that's all I need to know.

This. I've never seen any deliberate implementation of race condition (at least not before Shauns post ), but sometimes it's just too hard to code without them. Especially if something has to be done quickly ("customer wants it for tomorrow"-type). I'd be very, like VERY, unhappy if LV would break my quick workaround code and disallow its compilation because of possible race, which I'm fully aware of. And sometimes I might even have some clever anti-race chunk of code, which compiler might not understand. On the other hand, I'd be very happy to have helping LV hand which would tell me "hey, there might be race condition here, check it", but without the VI-breaking part. Generally, I don't think that breaking the code is good idea to fight any of bad programming practices. Imagine that some begginer, who just started using LV, or even started programming, see error about some "possible race condition due to wrong usage of global variables". He'd just be confused. Or even worse - he'd blame LabVIEW that it does not allow him to run his programs and just throws errors at him, and we all know where he would go from this point.

Hi, just a quick question. Take a look at the attached snippet - I'm creating virtual folder inside of a library programatically and I wonder if I can cast it to anything or is it just ProjectItem? There are 3 more sophisticated types of "folders" in VI Server hierarchy (LVClassPropDefFolder, PropertyFolder and XPropertyFolder), but maybe I've missed something?

We've set up Jenkins once and used it for a brief moment, but it was just experiment to see how it works and we've left this after several weeks. The real show-stoppers were some nasty bugs in compiler in the project that was our guinea pig. Those errors were unrelated to the CI server, but the result was that none of the compilations could be finished. The application builder is very moody - it can break without apparent reason in the first run, just to succeed in second. That is for sure one of the things to considerate when setting up CI. Anyway, I still see many advantages of CI, so I'll follow this thread with interest and maybe come back to the idea.

hooovaah, I've looked at this code and poly-VIs looked like obvious solution for that kind of code for me. But that doesn't mean that my solution would be better You're right - I've never developed any XNode. And that's why I wanted to understand, why this was the developers choice for this toolkit, why was it better to use them here. Your post gives me full answer to this, so thank you for that - and I'll leave XNodes themselves for other occasion, as I also don't want to make too much offtopic here.

Out of the pure curiosity: if you wanted to make functions adaptable to connected data type, why didn't you use polymorphic VIs? XNodes are undocumented, unreleased and unsupported feature, so the usage of this toolkit in production code is very limited (if not impossible). I think poly-VIs would also be easier to implement for you and easier to use by end-programmer.

Together with classes wires, you can make nice conveyor belt if your dataflow ever gets clogged