LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Extend on the concept of the termchar to include a multicharacter termination string for VISA reads.

 

Ideally, the termination string could be defined as a regex.

 

When I establish a connection with a linux based Device Under Test using a terminal server or TCP socket, the device ready prompt is the typical username@hostname:#

 

I currently read the VISA session in a tight loop a byte at a time and buffer the characters to compare to a regex of \n%s@.+?:[~|(/(\w)+)]+?# 

 

The time required depends on the length of the response from the device under test, so I have to keep track of the total time myself; I can't use the VISA timeout.

 

If NI-VISA supported a regex based multicharacter termination string, I could set my VISA session to look and wait for the prompt.

 

NI-VISA TermString.png

In the old days when VISA was first designed, I'm guessing that this sort of functionality would have been taxing on the memory and CPU. With today's 64 bit GHz multicore processors, abundant RAM and common regex libs, I don't hink this would affect timing.

 

 

Working with XML is fairly common and an addition to the palette to replace a specific node value would be helpful. Besides, there's lots of space there yet.

 

This link saved time. Thank you to juliodia

for posting this.

 

https://forums.ni.com/t5/LabVIEW/XML-Update-Element-Text/td-p/1239026?profile.language=en&lang=en

From:

https://forums.ni.com/t5/LabVIEW/possible-to-change-opc-ua-alarm-limits-at-runtime/m-p/3688481

 

The request is mostly in the title. Right now it seems as though changing an alarm limit requires stopping the OPC UA server. It seems reasonable to expect that users may wish to adjust alarm limits on the fly -- for my use case, tuning the system during a long commissioning process. It might be many months before a system is fully ready to go, and during that time alarm limits change regularly and we still want to report alarms to operators during this period.

Hello,

 

I'd like to humbly and respectfully suggest that "Internecine Avoider.vi" be rewritten or at the very least, refactored extensively.  (again)

 

This VI is found in "TCP Listen.vi", which is on the TCP palette.  It maintains a registry of existing listener connections and attempts to reuse them.

TCP.png

 

What's the big deal, you ask?  Well, when I'm having problems with listeners and need to figure out what's going on, sometimes I need to look into this VI.  Like a lot of NI code that I generally trust, I would ordinarily skip over this and disregard it as a possible source of problems.  The trouble is, every time I look at it I can't easily decipher the nuances of what it does, given its messiness.  Thus, though it may be perfectly functional, I don't trust it.

 

I realize the code could be a whole lot worse.  I also realize that someone has been in there since LabVIEW 2011 was released and has made some improvements.  Smiley Wink  Kudos to that individual for all the new free label comments.

 

Nonetheless, here are some factors that obfuscate this VI:

 

  1. There is no documentation under "VI Properties".  What does it do, at a glance?  (I know the answer because I've stared at it over a few versions of LabVIEW)
  2. "TCP Listen Internal List.vi" also has no documentation under "VI Properties"
  3. Without nitpicking, there are some sloppy practices employed in here that don't make a lot of functional sense.
  4. Deprecated "Retrieve Element" case in the internal list VI.  "Item Requested" is no longer a requested item, but the result of a search on elements.
  5. "net address" is confusing and ambiguous  Couldn't this be named, "Address of Listening NIC?" (Yes, I know it's documented under LabVIEW help for the TCP listener VI)
  6. "Conflict" is ambiguous.  This should be renamed to something more intuitive like, "Conflict: Multiple NICs Using Port" or something similar.
  7. Un-typedef'ed clusters in the internal list VI, with deceptive ordering of elements, combined with unnamed unbundler functions.

... etc.

 

I got to thinking... I know it works, or at least I think it does, but couldn't this be done more simply and elegantly?

 

I know, I know, "If it ain't broke, don't fix it."  ... but I think it could still use some work to make it more intelligible.

 

Respectfully,

 

Mr. Jim

 

InternecineAvoider.png

For accessing Linux in our products we will have an on-going need for Telnet.  The Internet toolkit is no longer supported, and though we can keep bringing the latest one (2012) along, it doesn't seem wise to build on an old toolkit.  It would be great if Telnet and SSH were native to LabView in the future. 

The current way to bind many shared variables to an OPC client, is through browsing a tree and selecting.

This is very time consuming when you have hundrends or thousands of tags to bind. Specialy if the all the tags are not in the same path.

A better way, is to bind the variables, by simple text.

Example: We will insert the following text

A1M01Z1:value

A2M01Z1:value

A3M01Z1:value

 

and LabVIEW will automatically create 3 variables, bounding to those addresses (with the same name, prefered). Many OPC Servers supports this type of address.

Note that the true path of A1M01Z1 could be something very big, like:

My Computer\OPC ABB.lvlib\_OPC1\[Control Structure]\Root\NETWORK 1\Nodecm3\Extended Process Objects\MB300 AI\A1M01Z1\VALUE

 

This way you can add thousands of items in minutes. It is quite easy for the R&D team to implement and will help many professional engineers.

Most probably, this idea will not accept many kudos, but i think R&D must consider to implement this.

 

(this was discussed with NI technical suport, Reference#3279019)

 

Thank you all, for reading

Please add to AF:

Interface based messaging. The need to create messages for all communication is a major decrease in productivity and speed of actor programming. It also decreases readability. It is a better with the BD Preview in Choose Implementation Dialog in LV19, but still.

 

Aren't you tired or seeing Labview, or LABview or LabView online?

 

NI Certifications (CLA, CLD, etc) should be stripped off people engage in miss-spelling LabVIEW.

 

And those who aren't certified should handwrite "LabVIEW stands for Laboratory Virtual Instrumentation Engineering Workbench" 10 thousand times!

Dear all,

 

timeouts and UID properties of "Modbus Master.lvclass" and "Modbus Slave.lvclass" can currently be set but not read out (they should).

 

See discussion here.

 

Sincerely,

Currently, the only way to add a webservice to a project, is by right clicking a Target and selecting New->Web Service.

There's no way to add existing Web Service definitions to a project, other than manually performing the copy operation at the XML file level.

This prevents proper re-use of IP!

 

Webservice in project.png

 

I would propose extending the capabilities of a Library to also support Web Service definitions as Child objects.

That way, the library can act as a container for the Web Service definition, and can easily be reused in other projects:

 

Webservice in library.png

I tried using an XML editor to manually put a Web Service definition underneath a Library, LabVIEW didn't like that!

It has been needed for a very long time to have web accessible front panels.  During the development of NXG this problem was solved with the web module.  I am not sure why they stopped development with NXG because was an extremely nice upgrade and was making Labview more future-proof.  NXG was then turned into G web development software.  Personally, I think the web portion should be an addon and native to Labview as eventually, that is where it will need to go anyway.  In the meantime, the only solution we would have is to possibly use G Web Development software as a front end development and regular labview as a backend.  To do this cleanly we would really need the shared variables available in G web development environment.  This would open back up doors that were closed once NXG was not supported anymore and would offer a solution until something native is added to Labview.  In my world, every customer wants and expects web-accessible applications.  I get the response all the time "Your software can do all of this control but isn't accessible from a browser on our LAN - my residential doorbell can even do that".  If I am missing some method to implement this currently (other than SystemLink) please reach out and I appreciate you considering some kind of solution to fill this very large need.

 

PS - I still don't understand why NXG support stopped if anybody knows.  Took a little getting used to but I saw big potential with that development software.   

I really like the option to use indicators (connected to the connector pane) as the output for webservice methods. By default, Labview will serialize it to JSON, but text and xml are also options. It works quite well and it saves a lot of coding writing your own serialisation.
I have some suggestions for the serialize functionality:

 

1. order the JSON output by tabbing order when there are multiple output indicators. This prevents that you end up always clustering all controls into one, just to enforce order.

 

2. it would be nice if an enum could be represented by its string instead of its index.

 

3. support for maps

Report Writer BEFORE WIndows 10 was SUPER ROBUST! Now that Windows 10 came along there exist many "turds" left in the Registry when folks UPGRADE from Office 7 to Office 10.

What happens is the Registry NEVER NEEDED to be kept clean of extra junk because NOBODY EVER UPDATED Office.

 

Now every Joe on the planet updates their Windows 10 with the latest Office 10..


What happens if they do NOT FIRST UNINSTALL, is the Registry is left with "turds"


When Report Writer uses ActiveX to make calls to use Word, in the old days, there was a SINGLE key in the registry to allow the calling program to gracefully start Word or Excel, or whatever.


NOW< with Windows 10 there are FREQUENTLY multiple "keys" in a Registry that causxe the LabVIEW Report Writer to "Gag" and "Hang up" doing nothing.


The SOLUTION is for the Report Writer to PARSE the Registry for valid keys and allow the request to be passed to the propper called process.

 

If this is not clear, please look up the SR below. There are a TON of examples and videos explaining how to fix it.

 

I have been working with LV since Dr. G was roaming the halls on LV 3...

 

This is the FIRST TIME Report Writer has gotten "sick".


This is an EASY FIX for the devs and since Report Writer is a purchased plugin they sould be able to update it so it works well.

 

Currently, they have us fiddling with the Registry or telling customers to uninstall and reinstall Office. That is a BIG FAT NO-NO to big companies because Office WORKS COMPLETELY for them and even programs like SolidWorks and DXP that use Word and Excel for stuff.

 

My number 831-455-0418

 

DEVS:

Please see: Request #: 00994109] Can not get EXE BUilder to run on WIn 10