Currently the build specification name, the output filename and output path of the build is hard coded on the "information" page of the Build specification properties window.
It would be a HUGE help if optionally the version number from the "version information" page could be added to the build spec name / filename / path. Right now unless I continously change the filename and folder path the project explorer overwrites the existing build and just by looking to the file name I dont know which build is this exactly.
This idea is not to take the awesome OpenG functions and make them native. This idea is to take the native functions that exist today, and extend the functionality to mirror the OpenG equivalents. There are several functions to talk about and I realize this may make this idea fragmented, but they all have to deal with File I/O functions, that are native, but lack the features of the OpenG equivalent.
Generate Temporary File Path
Here we see the OpenG Temporary File Name allows for specifying the file name and extension. So for instance my name can be "My Temp File %d.hoo". I can also specify a subfolder to put things in, which makes cleanup easier because I can just delete the whole subfolder when I'm done. This can make a files in "%temp%\Applicatoin Temp\My Temp File %d.hoo", but the native function can only speicfy a extension for the temporary file.
Here we see the OpenG Strip Path Extension accepts a file and returns the root and extension. Here the function is polymorphic and accepts a string, a path, an array of paths, or an array of strings. This can be helpful if you have a file name and want to get the root and extension. OpenG also has a Convert File Extension which can replace a file extension if one exists. If one doesn't exist it adds one. This also is polymorphic and accepts a string or a path again useful for a file name, or a relative and absolute path.
The native function only works on paths, and there is no convert function.
Build Strip Path
Here the OpenG functions are polymorphic. The Build Path accepts a path as the base, or an array of paths. The name or relative path can be a string, or an array of strings, or a path or an array of paths. And the Strip Path accepts a path, or an array of paths to strip. This is 8 polymorphic types between the two functions, but the native functions combined only have 3. The native Build Path accepts a string or path as the name or relative path, and strip path isn't polymorphic at all.
For existing functions I understand NI hasn't changed much but when NI introduced the Get File Extension, and Generate Temporary Path, I was confused why NI wouldn't try to duplicate the standard OpenG functions. Sorta like how when NI made the Clear Errors accept an error to clear why they didn't implement the function similar to OpenG's filter errors which is polymorphic.
please add the possibility to sort the bookmarks by column so I can choose to sort it by column "Bookmarks". I'm using it for documenting changes in different VIs like:
"#Change 20150125.1023 Removed code here....."
At the moment the bookmarks are sorted by VI name:
I have used Packed Project Libraries (PPLs) in a couple of smaller projects before with mixed amounts of success. Now I have read all of the caveats/pitfalls and I have a pretty good understanding of how they work (same application instance but under a different namespace) but my main problem still comes down to this: Passing class references into PPLs just breaks and causes me severe headaches.
Here is the situation...I pass everything I need into my plugin VI as a variant because within the PPL, you can do 'variant to data' and even if it is a type definition it will collect the correct reference which is valid in my application. This doesn't work for classes - the variant to data node complains because the data type does not match:
Error out 2 throws error 91 whilst the others are fine - even the user event which is based on a type definition in a library - QMH.lvlib:ctl_Msg.ctl.
The reason for this is that the variant passed in Class.lvclass and the data type it's trying to convert it to is Plugin.lvlibp:Class.lvclass. Apples != Oranges. The problem is that it IS the same class so I don't see why I should get an error here (because QMH.lvlib:ctl_Msg.ctl also becomes Plugin.lvlibp:QMH.lvlib:ctl_Msg.ctl, right?). If the type/class version/mutation in the PPL is incompatible with the main application instance then throw an error but if it's just because the namespace is different I want to be able to use that class in my PPL.
Can I please tell LabVIEW somehow that Plugin.lvlibp:Class.lvclass is actually Class.lvclass (including any classes used inside) so that I can use it inside my PPL with the same data space.
This sort of transfer mechanism between namespaces is already sort of possible with the 'Get Exported File Path' VI, so can I have a psuedo-equivalent for classes please?
I know I can build Class.lvclass and all of it's dependent classes into a 'shared' PPL but that would mean shipping my re-use library as a PPL and all sorts of other reasons (like not shipping vi.lib as PPLs).
I'm not actually sure what the solution would look like - there are far more intelligent people than me on here who can put forward some ideas of how to implement the idea - all I know is that I want to be able to pass my class into the PPL and have it work.
NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.
I suggest that NI start shipping USB keys instead. USB has several advantages:
Customized booleans with independent sizes and bounding rectangles for each of their four button states would open a number of possibilities, some cosmetic some funcional, for FPs. For one use case, see this thread. Presently they can sort of be created (Customize control/Operate/Change to Customize Mode/independent sizes etc.) but the resulting dimensions and the relative placement of the elements in the various states are absolutely unstable (possibly internally undefined?), making the technique borderline usable.
As a new adopter of the Unit Tetst Framework I was keen to export my UTF Results from the Result dialogue for use in an external test report (Word document).
The Save button creates a datalog file only suitable for Loading back into the same dialogue. There's no immediately obvious way to export your results in a readable format.
After scrutiny and assistance I found that you can configure automatic creation of HTML, ATML and ASCII formatted reports by changing your Project settings. Hmm. Not quite what I want.
I want to be able to quickly and immediately export my UTF Results to Clipboard or File in my chosen format from the UTF Results dialogue please.
A BD control/indicator/constant can be changed to either other type by contextual menu. For individual objects, Constant as well as Show/Hide are a choice; but for multiple selections, not -- why?
VI Analyzer seems like a really great tool but sometimes VI analyzer can't gauge the code intent and the author might have a legitimate reason for breaking the rules.
The current method of handling this is, for some tests, you can set a maximum number of allowances per VI, or, you can skip the test altogether for certain VIs. The problem with those methods is that they have the potential to hide legitimate issues and they don't document why a certain test was deselected.
I propose we add a way to document the issue (either in comments, labels, control documentation, etc) and have VI analyzer ignore or hide the authorized exceptions.
When programming in FPGA, all the timing functions are polymorphic, meaning you have to configure it for either ticks, us or ms. If your not carefull, this can sometimes lead to unwanted error due to simply overlooking a wrong configuration, as in the following example picture:
I propose a simple indicator or different icon to easily see the difference. Something like this, only maybe better looking:
My particular use case involves TCP Connection RefNums and Queue Refnums, but this could be applied to ALL refnums, as well.
When passing a RefNum from one VI to another, I realize it's not useful to show the numeric value on the front panel connecting control/indicator.
However, what WOULD be useful is to indicate when it's a Not-A-Refnum.
Perhaps a red dot, or a red background, would indicate that this Refnum is Not-A-Refnum, and absence of the dot, or a plain background would indicate the opposite.
I'm about to upgrade from LV8.2.1 to LV2013 and then there is a lot of unsupported properties and methods in the new version.
It would be very nice to have the possibility to find those unsupported stuff.
Actually NI seems to need that function too. smileywink:
Take a look at this thread I made a while ago.
I tried to parse the output-file from the "Export Strings" function with the LabVIEW XML-Parsing function, but neither the standard (string) XML functions nor the VIs provided with the XML Parser Lib provide satisfying results.
For localisation and string manipulation in a VI it would be a great help, if this output file could be somehow parsed and processed with a (self written) LabVIEW Tool, but unfortunately it's realy hard to get the data into a structure for further processing in LabVIEW.
An alternative could be if LV exports the strings into an binary file, and NI provides a typedef to parse the data against.
I like to suggest ECU Measurement And Calibration Toolkit to support XCP on FlexRay. FlexRay become available in more and more products, and XCP support it would increase the usability of XNET HW.
since FlexRay is rising in more and more products, a FlexRay support is needed. I suggest to extend the Automotive Diagnostic Command Set to support UDS on FlexRay, too.
I've made my own copy of the actor framework to implement some changes that I really needed. Because of this I cannot really share code easily and my framework branch is not automatically updated. The changes that I've made could be made without overwriting the framework if only the framework was more open.
(a bit of what you can do with the changes are listed in brackets)
Creating more functionality for actor framework classes should be done through children of the classes in the framework. The way the framework is setup makes it impossible to add functionality to some classes:
- Message Priority Queue
- Message Enqueuer
- Message Dequeuer
- Message Queue
These classes are all obtained with a class constant internally in the framework.
I would really like it if we could have a class input to all these so we can implent additional queue functionality and have this input as part of either an actor dynamic method inside of the Actor.vi that the constants are read from or an input to the launch VIs.
[Magic can be done with enqueue in front combined with batch message children and public scoped read self enqueuer --> self propagating message array]
Changing functionality through dynamic dispatch is the way it's meant to be done. But most of the Actor framework VIs are static dispatch. Vi's that I'd like to make dynamic are:
- Launch Actor Core.vi (and probably all the other launchers as well)
- Send Message and Wait For Response
- Send Batch (Or change the class constant to a control
[adding a counter to an actor child would be easy with a dynamic dispatch of Launch Actor Core]
Heavy use of access scopes makes some actions impossible (as intended). I'd like to have the following changed to community scope and added as friends to the Message class:
- Read Self Enqueuer
- Read Caller Enqueuer
[Messages that flush the queue, view the queue status enqueues them self on the queue and so on can be made]
And lastly but surely the most controversial is the change of pre launch init from non-reentrant to reentrant.
Yes by doing this and launching an actor from within the vi will crash your program. But doing it as is will result in a deadlock anyway. The protection of making it non-reentrant is extremly weak! I'd rather have some warnings. What you gain is that the actor that you are launching and the nested actors that it will launch from the pre launch init can share their private data during launch! This is extremely useful with actor shared notifiers, DVRs and so on. Note that you can do this halfway by launching from the actor core.vi however the data will only be shared up in the hierarchy not throughout the entire hierarchy... which is bad/sad.
I hope you'll look into at least some of this to enable a more dynamic usage of the framework for advanced users.
The Enums types are very cool for "case structures" handling inside VI's block diagrams.
It is also easy to use them in Front panels ...
But, when you have to create multi langage applications, you have to face a big problem :
=> The visible Enum strings cannot be modified !
It should be cool to be abble to modify the Strings viewed by an Enum using a property.
You may say, I should use rings, or fill a combobox ... I know ! That's what i am using today !
But it should be so nice to have such a feature.
=> My reccursive automatic VI front panel translator would be abble to translate Enums dynamically !
The Enum translation will not need any additionnal coding actions !
Thanks a lot.
Allow BD code and FP objects to be copied to the clipboard from a VI in an older version of LabVIEW and then pasted into a VI in a newer version. If the code is obsolete or contains depricated functions then it should be processed the same way a VI is when loaded into a newer version of LabVIEW.
There are suggestions on the Idea Exchange to annotate subVI nodes with various attributes (this one, for example). I think that's a losing strategy. There just isn't space for all the annotations that might be of interest on a given node, and not all of the annotations make a difference to user's understanding of a given node. As an example, knowing that a subVI is reentrant is very important to understanding how a point-by-point read subVI works but unimportant to understanding how Trim Whitespace works. Also, not all of the annotations that we could imagine are simple "on or off" settings. A subVI that uses a local variable might be using it in an iterative algorithm or might be using it to store state between calls. If it is storing state, that might be something that a caller should know about.
These are the sorts of things that could be scanned for on a VI when LabVIEW launches the Icon Editor. If we had standard glyphs for interesting attributes of a VI, LabVIEW could have a section to recommend glyphs to add to the icon. This would not be an automated "always add this glyph" system that some people have requested because I do not think that we want the glyphs on every node just because it has the attribute. But some nodes it is worth calling out, and putting it in the Icon Editor would make it easy to add such glyphs. We might even have a fast "add recommended and arrange layers" button that spills all the glyphs onto the icon and then moves them around to minimize overlap, taking the existing layers into account.