Neil Pate

Ah yes, now I recall that thread, thanks. (I confess I did not google it, getting lazy in my old age...) I am a bit on the fence on this, will probably try it out for a bit and see how well it fits into my workflow.

Hi all, I remember some time ago a discussion somewhere (cannot remember where) about the possibility of a Variant To Data figuring out which data type to output depending on what type the output was wired into. Even though the type input is shown as a bold input (i.e. "required"), it is possible to leave this off. I have always manually placed down the desired output type, just as a force of habit more than anything else. It seems that as long as there are no other structures in the way the Variant To Data is able to figure out the type it is being wired into, so is there any sense in placing a type constant? Interested to hear what others do here.

I did not know that was possible, cool. However that sounds like a lot of work for a LabVIEW programmer

Yeah I kinda expected it... It's a bit annoying really, it is not like Windows 10 was all of a sudden released on the world with no notice. So strangely I was poking around in my Vision pallette and even though I had to switch off my Pc during the installation the IMAQdx VIs are there. Will probably go up in smoke if I try and run them though Edit for grammar

Hi All, I have recently cobbled together a new PC, and have put Windows 10 on it (which I really like). Everything works quite nicely, but have had a lot of trouble installing NI Drivers. I have the August 2015 Software Reference Library USB stick, and cannot install DAQmx or Vision without the installer hard-crashing my PC (power off required!). I have no issues installing other software (LabVIEW, toolkits, TestStand etc) off the USB stick. I was able to get DAQmx to install by using one I downloaded, but this technique has failed me for the Vision drivers. Anybody else experience this behaviour? I would suspect it is just something about my system the installer does not like. I have a pretty new Skylake based CPU so perhaps that could be it? Kind regards Neil

Right, well then I will truly park this for now. Thanks for the info Rolf.

Thanks guys, I did not know about the menu being non-standard. Do you think there may be some way in via the Qt DLL? Actually, there is pretty much zero % chance I am going to have time to explore that. Will just have to live with it for now.

Hi All, Does anybody know how to set the menubar colour in an application? I have done some digging and it seems this is possible using the windows API, just wondering if LabVIEW had some way to do this natively? (I doubt it, just thought I would ask).

Hi there, Has anybody used the OPC UA client that is part of the DSC toolkit? I am trying to use it to connect to a PLC and am getting error -336653 "The status of the OPC UA server is uncertain" I am able to create a local OPC UA server in LabVIEW and connect to this with no issues from the LabVIEW OPC UA client, and can connect to the PLC just fine using a different client. After speaking with NI it looks like this may be a permission issue, but I have tried all the obvious things in the OPC UA client (like client and server certificates), with the same result. Any tips? Crossposted http://forums.ni.com/t5/LabVIEW/OPC-UA-client-cannot-connect-to-PLC/td-p/3195246

Any suggestions for Chrome?

Yeah I want to try and use FTP to download things like DAQmx without having to go through the NI downloader which I find gets quite choked sometimes. Thanks for the FTP link, that will be useful for LabVIEW related stuff.

Hi All, I am trying to get a new PC back up to a usable state (installing software etc). Am having some trouble accessing the NI.com FTP site. Using filezilla I can access ftp.ni.com with no problems, but cannot get find support/softlib where the juicy bits get downloaded from. As I said this is a new PC so I had to create the FTP connection from memory, have I done something stupid like not put the right authentication or something?

I am also getting on OK with Win 10. The start menu behaviour annoyed me so I installed Start10 which makes it behave more like a hybrid of Windows 7 (which I thought worked quite well) and Win 10. You can pin as normal, I have multiple versions of LabVIEW pinned.

I agree the problem stems from calling them "wires". In LabVIEW all wires obey data-flow, period. Queues and other reference type constructs are not wires, they have a wire to represent the their reference, and that wire does obey dataflow, but the actual implementation of the queue does not live on the wire. So, I do am not really that keen on the name "Channel Wires". I would have been totally fine with just "Channels". However, I am pretty sure I will just get used to them.

Definitely. I am speccing out a new PC and plan on having two SM951s (NVMe) into RAID0 for a theoretical read rate of nearly 4 GB/s :-) (yup thats giga-bytes per second)

I am thinking of putting together a benchmarking application that can be used to roughly gauge a PC/target's performance. Kind of like a FutureMark 3DMark but for LabVIEW code. Has anybody done anything like this? I know we all do lots of informal benchmarking of code to test performance of different algorithms, I am suggesting pick certain algorithms and then benchmark against different hardware/OS etc. Does anybody have any recommendations for test suites to run? I was thinking things like encryption algorithms, linear algebra, large FFTs etc, mass compile etc Would love to hear thoughts on this.

Whoooosh....

In the seven or so years I have been dabbling with LVOOP not once have I said, "gee I am so glad that a class maintains its mutation history". Maybe it's just the kind of applications I develop, dunno. I never serialise my classes directly to disk. Also have seen some terrible editor bugs that can be traced down to stale mutation history in a class.

Sorry, sounds like you know more than I do about shared variables. Can you see the variables using the Distributed System Manager? Have you taken a look at Network Streams? I find them much easier to setup and debug when things don't work. Think of them as TCP/IP with all the re-connection and other management stuff taken care of.

It may be down to the fact that the hostname portion of your variable URL (i.e. RT CompactRIO Target) does not make sense when running the code in the context of the cRIO. Try something along the lines of ni.var.psp://localhost/ etc etc I am not a big fan of shared variables, and try and avoid them whenever possible.

I kinda like manually adding in the Action Engine wrappers (which I do religiously for FGVs and Action Engines). I create them one at a time and test them out as I flesh out the test harness. Sure, takes a little bit longer (than scripting for example, or using GDS), but it gives my brain time to think about the names chosen for the enum values and the names of the wrapper VIs. Often holes in the API become obvious just when thinking about how the accessors will be used.

I believe this is by design. Occurrences are slightly different to other kinds of reference (like notifiers etc) and the actual occurrence reference is determined at compile time or something like that. I remember reading something about this on ni.com years ago. Will try and dig it up.

It's been a while since I did mine, so my memory is a bit rusty, sorry. I think I did not use a template as it would have required too much changing in the heat of the exam (I don't really like the templates shipping with LV), but I did borrow some elements from some of the templates though. The one thing I think I did re-use was the queue handling mechanism as this was neatly wrapped up and easily copied out a sample project. Don't beat yourself up, the CLED was one of the toughest exams I have done. Three and a half hours in I honestly felt like getting up and going home (to sulk), and I am pretty sure ten years ago I would have done that. Instead I managed to knuckle down and passed. In the exam I also had some weird connectivity issues with the RT target, and spent way too long trying to get my build to deploy properly. I probably wasted 30 mins doing this before saying screw it and just leaving it.

Thanks for this tip. I have made the change and now I just have to wait for my application to fall over (or not fall over, hopefully!).

<possible thread hijack> Jack, I had tried to do something similar with the threads just yesterday. Do you know how to achieve this in a built executable? Unfortunately threadconfig.vi is a GUI type VI, so not really able to be embedded into another application. I was able to get the contents of this VI and remove the GUI aspect and then inserted it into my code. However I am not really sure this will do what I want as I do not know if it is possible to modify the thread configuration from a running application? Perhaps I need to modify the LV IDE settings before building? </possible thread hijack>