By Ryan Vallieu
I have seemingly found an issue with the shipping example code for Nested Malleable VIs. Another user has verified that he saw the same behavior in 2019.
I am working through the examples and the presentation from NIWeek 2019. In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed. When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi.
One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same. The Equals.vi code looks identical, and the calling VIM look identical. I posted on the LabVIEW NI.com forum here:
I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.
Started some work on a simple C code generator for LabVIEW.
I was working on some ideas to handle some more complex Items. Had some thought about using
To handle strings and other arrays/vectors, I would like to pass these more complex data types by pointer. However I am looking for some ideas as to when to make a copy. I know LabVIEW has some internal item that manages this but I haven't found a way of accessing it quite yet. Let me know if you think this is worth some effort. Or if you have any ideas about the architecture that you think would be helpful.
Also i imagine that this will still only ever support a small subset of LabVIEW, the languages are quite a bit different, and i prefer that the code be as clean as possible.
For those who have been playing with malleable VIs, the Type Specialization Structure has probably become a common sight and much abused tool.
The basic use of it is that if the action it performs is meaningless given one of the inputs, the included code will break and the next case will be tried.
This is great, but sometimes, it can be difficult to think of all possible variants of an action, and in particular, if the action needs to be different for two or more types, but two or more types are compatible with different codes, how to make sure which code will be executed with what type?
Enters the Types Must Match function:
I found this little gem in... Hidden Gems, within an odd-looking VI which I felt compelled to check out, Debug Write.vim
Open its diagram and light will shine, opening grandiose vistas and parallel universes remaining to be explored.
Of course, as the comment on the diagram says:
"This structure and the type-testing primitive functions it contains are not public LabVIEW features. They are experimental and should not be edited, copied, or used in other VIs without conducting extensive testing. See Context Help for details."
Here is the context help for Types Must Match:
My apologies if this all well-known among expert users, but I couldn't find it mentioned otherwise on the site...
Hi guys! I know that it is an old topic , but I will try !
My DAQ board sends to PC data in the following format.
! is the starting character
and we have "," , ":" and ";" as delimiters.
In the end of the packet (after ":") my board sends the values of two microcontroller timers (4 and 5).
The first data packet ends with a <CR> and my boards repeats that every 3 seconds.
I need to plot voltage1[n] and voltage2[n] in two separate graphs and my time base is the value of TIMER4 / n.
The real data is like showed below.
I have used and modified altenbach's VI (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Contract-multiple-delimiters-for-quot-Spreadsheet-string-to/idc-p/1239830#M7564) but some delimiters are bothering me yet.
Modified Altenbach's VI
Case value 1 detail
The result is:
The VI was great to separate correctly the values of voltage1 and voltage 2 in two separate strings but I did not know how to avoid the last comma.
Also in Timer4 and Timer5 I could not avoid the characters ":" and "," right before the numeric values.
I would be grateful if anybody help to solve this issue or give me other tips to do what I need with that data.
Thank you everybody in advance !