Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JKSH

  1. I just logged in, and I'm able to browse forums threads just fine. Windows 10 version 1703 x64, with Microsoft Edge 40.15063.674.0
  2. When you break down your string into different sub-sections, the problem becomes much easier to solve. Don't try to handle 4 delimiters at the same time. The format for the full packet is: !<VOLTAGE_LIST>:<TIMER_LIST><CR> The format for <VOLTAGE_LIST> is: <VOLTAGE_PAIR[0]>;<VOLTAGE_PAIR[1]>;...;<VOLTAGE_PAIR[n-1]> The format for <VOLTAGE_PAIR[k]> is: <VOLTAGE1[k]>,<VOLTAGE2[k]> The format for <TIMER_LIST> is: <TIMER4>,<TIMER5> Notice that: The full packet only has '!' at the start, ':' somewhere in the middle, and '\r' (<CR>) at the end <VOLTAGE_LIST> only has 1 delimiter: ';' <VOLTAGE_PAIR[k]> only has 1 delimiter: ',' <TIMER_LIST> only has 1 delimiter: ',' You can translate the above breakdown into very simple LabVIEW code: Notes: The pink VI is <vi.lib>\AdvancedString\Split String.vi To make it appear in your palette or Quick Drop, install Hidden Gems in vi.lib from VIPM or http://sine.ni.com/nips/cds/view/p/lang/en/nid/212430 Alternatively, you can use OpenG's String to 1D Array.vi Regular Expressions (Regex) are very useful for string manipulations. Play with it at https://regexr.com/ (note: You might need to replace '\r' with '\n')
  3. That looks nice! It makes the safety logic easier to implement and understand. It's nothing like the LabVIEW State Chart Module, however: "With state diagrams featuring up to eight individual state machines per module, you can complete your programming. You can use AND, OR, and NOT logic along with programmable timers to determine when to transfer between the various states. In addition, you can assign up to 24 Boolean variables. After you download the safety logic onto the module, you can monitor AI, DI, DO, variables, and diagnostics in the LabVIEW Real-Time Module." There are no VIs involved at all.
  4. We used it in a few projects, but the biggest one which had lots of state charts became really slow to deploy. This made our workflow quite inefficient, as each time we wanted to update and test some code on a cRIO we'd need to spend ages waiting for the state charts to deploy (even if we haven't changed anything in the state charts or their VIs). The module's implementation doesn't scale well. From what I've seen, the State Chart module isn't that popular in Current-Gen LabVIEW. I think it's unlikely the module will migrate to NXG, not without being re-designed from scratch.
  5. JKSH


    When you say "LV stops", I'm guessing you mean you stop your VI and return to Edit mode? Note that LabVIEW itself doesn't stop. Anyway, are you talking about cleanly shutting down your VI, or aborting it? If clean shutdown: Does it help if you make your framework explicitly un-insert subpanels during shutdown? If abort: I'd guess it's a reference that wasn't released properly. I haven't seen this, but it looks like a bug. As @Aristos Queue said in https://lavag.org/topic/20315-xnodes-prevent-inlining/#comment-123550 -- "Only squeaky wheels get grease", so do submit a reproducible example to NI if you can!
  6. Hi Sean, When should users use this proposed site, and when should they use the existing LabVIEW tag on StackOverflow? (https://stackoverflow.com/questions/tagged/labview ) IMHO, the example questions (currently 4) fit well on StackOverflow. So do the other NI application families that you mentioned (LabWindows, TestStand, NXG, USRP & VeriStand).
  7. So you want to convey the idea that the code resists/frustrates efforts to maintain and scale it... I quite like brittle that others have already suggested. Throwing some more ideas out there: Inflexible Intractable Tangled/Entangled Over-coupled/Excessively coupled Unmodular(?)/Non-modular Restrictive/Constrictive Unbending Note: The first 2 candidates fit your existing pattern of the "in-" prefix: Incorrect Correct, but Inefficient in performance Efficient in performance, but Inflexible in design If you have time, I suggest asking at https://english.stackexchange.com/ for "harder than necessary" in the context of designing software. You'd get a lot more eyes and brains there.
  8. You have my sympathies. It is always horrible when someone who has authority over you (or has the ability to make your life difficult) doesn't get their facts right. Worse is when they refuse to even look at a piece of evidence that shows them wrong... What will happen if you point IT to the Windows + Git scenario? I don't suppose you can talk to the legal team directly? Your code sounds safe, then. To reiterate: If your code calls VIs (or DLLs) that are licensed under the GPL, then your code has to be GPL too. However, this does not apply simply because you use a GPL'ed program to manage your code. BTW, the term "tool" is quite ambiguous. I suggest referring to the things that you download via VIPM as "libraries"/"packages". Git and the GCC compiler are examples of GPL'ed tools that you can use at work without making your code GPL. This sounds like a reasonable feature request. @Jim Kring? If a project large enough that it depends on lots of different 3rd-party libraries/packages, then it makes sense to carefully track the versions of your dependencies anyway. Doing a blind upgrade puts your software at risk of bugs, regressions, or plain code breakage. I'd say these are much greater risks than a sneaky license change. Anyway, the common open source software licenses (e.g. BSD, MIT, (L)GPL, Apache) don't expire. Once a version of a library has been released to the public under a particular license, you will forever be allowed to use that version of the library under that license. It doesn't matter if future versions of the library are released under different licenses. So, all you need to do when you re-install LabVIEW and your dependencies, is to install the same version of the dependencies that you were using before. Only update the libraries/packages if you want to take advantage of a specific bugfix/improvement -- this is when you should check if the license has changed (and make sure you perform tests for regressions). The requirements are part of the license itself. The BSD license asks you to "reproduce the... copyright notice, [the] list of conditions and the... disclaimer in the documentation and/or other materials provided with [your software]". I'm guessing it's less effort than what's been spent on the NI License Manager framework... I see the value of both FOSS software and proprietary software. Without the FOSS movement, I would unlikely have spent so much time tinkering with software when I was a student, and thus would unlikely have a job today as a LabVIEW developer.
  9. Ah, I just realized that I might have misunderstood the original question. @0_o, could you please clarify: Which do you think is GPL -- VIPM itself, or the tool that you downloaded through VIPM?
  10. The usual disclaimers apply (i.e. "I'm not a lawyer"), but... I am absolutely positive that: If you're just using a GPL'ed tool to manage your code or your workflow (for example, source control) but your code doesn't actually need the tool to function, then you are not required to apply the GPL license to your own code and share it. On the other hand, if you incorporate a GPL'ed library into your code or if you link your code to it (for example, using the GPL package from VIPM), you are required to apply the GPL license to your own code and share it. Your IT department has misunderstood (or is misrepresenting) the GNU GPL. Wrong. Using a GPL'ed tool for source control does not make your code dependent on the tool. Thus, you are not required to apply the GPL license to your code and you don't have to share it. Here are some examples in industry: The source code for Microsoft Windows is now managed under Git (https://techcrunch.com/2017/05/24/microsoft-now-uses-git-and-gvfs-to-develop-windows/). Git is under the GPL license (https://git-scm.com/about/free-and-open-source), but Microsoft is not required to apply the GPL to the Windows source code. National Instruments uses Linux Real-Time in many of its devices, such as CompactRIOs. Linux is under the GPL license, but... NI is not required to apply the GPL to the CompactRIO software's source code. If you write software to run on a Linux-based CompactRIO, you are not required apply the GPL to your source code. (Side note that is irrelevant to your main issue, but is still useful to know: SVN is not licensed under the GNU GPL! https://en.wikipedia.org/wiki/Apache_Subversion Rather, it uses the Apache license, which is more permissive than GPL. Apache-licensed code is permitted in commercial/proprietary code. It is the TortoiseSVN client that is GPL: https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-preface-source.html ) Correct. Your code uses the GPL'ed VIPM package as a library, so your code must also be licensed under the GPL, which means you must make your source code available to your users.
  11. Have you installed the NI Database and Connectivity Toolkit?
  12. Have a skim through this thread, which discusses some of the quirks of type definition disconnection: https://forums.ni.com/t5/LabVIEW/Application-Builder-What-does-quot-disconnect-type-definitions/td-p/2992511
  13. To clarify @jacobson's comment: In your .lvlib, right-click your variable and select "Properties". Disable "Alarming", "Update Deadband", "Initial Value", "Logging", and "Scaling". Now, your variables will work with LabVIEW Runtime without the DSC module. I'm not sure I understand. The issue would be the same, regardless of whether you use raw TCP or Network Shared Variables, right?
  14. In JSON, square brackets represent arrays. So, this is an array that contains one Boolean element: [true] This is an array containing three Boolean elements: [true, false, true]
  15. There are two broad categories of objects/classes: Values (e.g. numbers, strings, URLs, timestamps, images*, tuples/collections of these) Identities/entities (e.g. file, physical I/O channel, physical device, database, GUI control/indicator/window, state machine) Conceptually, values can be copied but identities cannot. (To illustrate what I mean: Branching a string wire can create a new copy of the string, but branching a DAQmx Channel wire cannot create a new channel) I would use references as a last resort for "value objects", but as a near-first resort for "identity objects". *IMAQ images are by-reference, but they didn't strictly have to be. Genuinely curious: Why do you expect reference-heavy G code to be less performant?
  16. The bar edges look a bit blurry. Try sharpening your image and increasing the contrast. Do these help?
  17. JKSH

    SCC Role Call

    Git + SourceTree, for the same reasons as @LogMAN. I'm not getting JIRA for LabVIEW work, but I'm part of an OSS community that does use JIRA.
  18. I'm guessing it has something to do with the pricing of Application Builder -- NI is selling these for $1500. It's not clear to me: Does purchasing the license of Application Builder for one OS entitle you to the other OS'es...? Also, does the Developer Suite entitle you to LabVIEW on all desktop OS'es?
  19. This year, NI Week has a "Breakfast with the Execs" session, which lets attendees sit down with a high-ranking NI official and talk about specific topics. Omid Sojoodi, the Vice President of R&D for Application and Embedded Software, was taking questions about LabVIEW and SystemLink. I asked him about the Windows-centricity of LabVIEW NXG, and whether NI has considered cross-platform GUI toolkits. This is what he said: NI is currently concentrating their resources on maturing NXG on Windows, because it is by far their largest market. As of today, they haven't picked a solution for macOS and Linux, but are considering using web technologies (HTML + CSS + JS). During the early stages of NXG planning, the R&D team evaluated 7-8 cross-platform GUI toolkits. However, none of them were satisfactory. NI does use Qt internally, so they are familiar with it. It is one of the toolkits they evaluated. According to Omid, it didn't look native enough, so they went with a native toolkit (WPF). Personally, I'm surprised by this; I've used Qt lots and it produces very native-looking GUIs to me. In any case, I would've thought the cost of minor deviations from full nativeness (if any) would be dwarfed by the cost of maintaining separate code bases for different platforms. I also think trying to tack on cross-platform support after the maturation of the Windows version will be a very steep uphill battle, compared to doing it from the get-go. However, Omid did also say (in a different discussion) that LabVIEW NXG is very modular, and the front-end is quite separate from the business logic. Perhaps this means NI is confident of their ability to swap front-ends easily?
  20. Every endpoint needs a name. Network Streams are one-to-one: One writer sends data to one reader. Between this pair, only one needs to specify the URL. I presume that your cRIO's IP address is This is what I recommend: You don't need any context names. On your cRIO, set the reader name to "myreader". On your cRIO, do not wire anything into writer url. On your PC, set your writer name to "mywriter" On your PC, set your reader url to "//"
  21. This is not the official NI forum. Very few NI staff (who can actually fix your issue) come here. You're trying catch fish by shooting a rifle towards the sky...
  22. Kudoed. But anyway, have you seen VIMs?
  23. According to http://digital.ni.com/public.nsf/allkb/79CB44F7E228AED88625756E00445151?OpenDocument, "Compact RIO systems have a FPGA in the backplane which prevents DAQmx from being used" But just to be sure, I'd ask NI via official channels to get a definitive answer
  24. JKSH

    Advice on OPC

    I'm curious: What's the rationale for supporting NI clients only? I can confirm that I've used the API to host an OPC UA server on a Linux RT CompactRIO, and this server is accessible to 3rd-party clients. My test client was UA Expert (by Unified Automation). I don't know the exact model of my customer's client, but I believe it was by Matrikon OPC.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.