Phillip Brooks

Obligatory Bobby Tables reference

And you got none...

ser2net - shares a serial interface as a telnet compatible socket. Here's an example setup: https://garettmd.com/create-a-console-server-with-a-raspberry-pi.html

Killer feature: SSH 😆

More like the Hamburger Trick

EasyXML Toolkit

It reminds me of the old quote about solving a programming problem using regular expressions. Punch-line : "Now you've got TWO problems"

I thought I replied to your DM but I don't see it in my mailbox now. From what I can tell, the rectangular bar code in your image is classified as Data Matrix, ECC200, DMRE. I used Bartender to create an ECC200 type label and could NOT decode it with ZXING or the on-line decoder. ( https://zxing.org/w/decode.jspx ) I WAS able to decode both your image and my Bartender rectangular bar code with a Datalogic GD4400 scanner. I tried updating my ZXING assembly from the old 14.0 version to the latest I could easily find (16.4) but it still didn't decode.

Yes. 4 years ago, I took my current job because the lone engineer supporting the manufacturing of my product suddenly left. I believe there were multiple reasons, but after I got involved I realized that I would have probably done the same if I was in his shoes. There was 10 test stations running 5 test sequences for three specific products. The test system was based on an older version of CVI / TestStand with run time deployment that originated at a consulting company. The product under test has some diagnostics, but much is tested by configuring it as a customer would. The product software changed over time (as would be expected) and the tests stop working. Sometimes the changes demanded a change to the CVI code, but the previous engineer had no experience. Solution? Replace the functions that don't work with LabVIEW VIs! Move forward a couple of years and introduce new test requirements, new web based interfaces and the test system turned into quite a mess of curl, perl, CVI, LabVIEW and TestStand RTE. It got so bad that the product OS was locked down to a specific version of software and then upgraded at the end to the shipping software. CVI code would crap out when IT would install Windows updates (DLL hell). Test times per UUT went from an original 30 minutes were now almost two hours. The product ended up being tested twice just so we could install the latest software before shipping. First pass yield was 80% with the primary cause being test execution failure; timeouts exceeded and Selenium/Firefox step failures because of JAVA updates or an operator changing the screen resolution. This is where I came in. I dubbed the existing system "The Jenga Pile". Touch anything and it all came crashing down. It's easy to say that this is an implementation issue. My manager and I decided that we needed to move to a current version of Windows / LabVIEW / TestStand, get rid of cludges like Selenium and curl and rewrite the tests from scratch based on the latest version of the product software. I was 6 months and 75% or so into the project when the only early advance of the new product software was given to me. Many of my tests were based on a telnet session to the product. Telnet was now REMOVED from the product! (not disabled, but REMOVED - security issues ). I needed to change to SSH or use the serial console port. LabVIEW and SSH (don't get me started)?!?! I was already done with my test coding and intended to spend the last two months tweaking the TestStand environment and creating my first RTE deployment. I used SSH.NET here and there where necessary to recover. After taking 4 weeks to rework the telnet related issues, I found I could not reliably create and install TestStand deployments. SSH.NET would not work. Oops! Did I mention I had never created an RTE deployment before? My previous employer used debug deployment licenses and I never once dealt had to deal with the RTE. Now I know why. I told my manager to cancel the plans for upgrading our 10 deployment licenses and spent 4 weeks in overdrive creating my own crude sequencer and report tools. I saved the cost of NI upgrades, met the deadline and made my life easier down the road. Changes now only require compiling a new EXE and dropping it on the test stations. I have a UI that I can change, deploy in minutes and I haven't had to think about Process Models or creating 100s of MB of deployment packages for simple changes. It is not actor based or even very modular at this point. I love the promise of TestStand, but I'm not controlling a super-collider and certainly not doing rocket science. Give me TestStand Lite (google it) as an actor where I can register some LabVIEW UI elements to monitor and control execution. Give me TestStand Lite, limit the engine to running LabVIEW VIs and include the engine in the Professional edition. The TestStand Lite sequence editor should integrate seamlessly into the LabVIEW project.

Isolation? I've always wanted a reason to check this out: optical USB cable... https://www.corning.com/optical-cables-by-corning/worldwide/en/products/usb-optical-cables.html You would need to provide your own power to the camera at the far end.

Someone reported a similar issue on the dark side. Are you using typedefs? https://forums.ni.com/t5/LabVIEW/chm-help-file-and-executable/m-p/2703303#M802558

Don't use this functionality, but the NI Doc reference has a note: Maybe the exe is expecting to find the help file in the support directory?

You have to be in the control editor. Drop a control on a VI FP, select the FP control and use Edit -> Customize Control... from the pull-down. Now, in the control editor, select the control and select Window -> Show Parts Window

I would suggest posting on the NI forums and seeking out Mark Yedinak. He's works at Zebra and has been answering LabVIEW / ZPL related questions for a long time.

Look for vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi

Yikes! http://forums.ni.com/t5/LabVIEW/LV-2016-Known-Issue-583670-Can-I-really-no-longer-build-for-Win7/td-p/3341369

Are the client and server both running LabVIEW? Do you have tftp client or server available on either of the systems? tftp is UDP based, but takes care of the handshaking. https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol

https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53#.4476pk9xq

I remember reading about a VISA Python library a couple of years ago. Might make traditional instruments easier to interface to... https://pypi.python.org/pypi/PyVISA ( edit: Looked at PyGMI and it uses PyVISA and PySerial )

It depends on the structure of your data. The biggest hit reported by most users is when reading an array of clusters. http://forums.ni.com/t5/LabVIEW/Saving-Clusters-to-a-Config-File-Using-Variants/td-p/1586500 There is a VI collection called Read/Write Anything from Moore Good Ideas that might help. http://www.mooregoodideas.com/readwrite-anything-vis/ WIth such a large data file, you may want to consider switching to a different format, like XML or maybe even a database.

I found the root cause of the problem. I had an LLB file that contained a VI with an invalid character in the file name. LabVIEW would compile the VIs, but at the end of the compilation process, the files are copied into a folder named for your .exe. The invalid Windows file name could not be created, but the error message never contained the name of the file. I sent the LLB to NI and declared that I think this is a bug. I found it by converting all of my LLBs to folders using the LLB Manager. When I got to the problem LLB, the conversion reported an error on the badly named file. I copied the LLB, deleted the offending file, converted the copied LLB to a folder without error. I manually saved the offending VI as a file into the folder without an error. Then I could compile. I've had bad experiences in the past when I use "Save As" into an LLB to create a new VI. The "Save As" dialog is not a standard dialog and can act wierd when you use the control keys to move about within the name box. I might have somehow inserted a TAB or control character that LabVIEW was willing to accept as a VI name inside an LLB. LabVIEW just didn't know how to fix the name when saving it outside the LLB. I spent over a week screwing around with creating new projects, mass compiling and re-installing LabVIEW because of this. I know that many people will say "don't use LLBs", but this is the first time I have been bit by them in such a bad way.

So, Seven years later, I have a project in LV2014 that has been fine for months and it suddenly starts giving me a 'dirty-dot' on open and the same cryptic message "An attribute of the project was changed." when closing: I also can't create an executable: But the code runs fine from the development environment. I created a new project file and it has the same problem. Error when building: Anyone know how to fix this?