MichaelBalzer

2 hours ago, Ramya JM said:

Tried to install biomedical toolkit from VI package manager 

Exit LabVIEW and VIPM, then run VIPM as administrator, then install the Biomedical toolkit.

If you're running LabVIEW 64-bit, you'll also need to update one of the toolkit's dll files. The toolkit states it supports LabVIEW 64-bit, but the bundled LVDICOM.dll file is 32-bit only. There is a 64-bit version of the dll available on the NI forums, which will need to be copied over the 32-bit version found in C:\Program Files\National Instruments\LabVIEW <version>\resource

You'll need OpenG Zip 4.1.0, which includes support for Linux RT (afaik this isn't available through VIPM, only from the forum). Once installed, use MAX to install a 'legacy' custom software image on your sbRIO, and include the OpenG ZIP Tools package:

Alternatively the required library file found in C:\Program Files (x86)\National Instruments\RT Images\OpenG ZIP Tools\4.1.0 can be copied to your sbRIO:

Quote

Depending on your target you need to copy the according liblvzlib.so from either the LinuxRT_arm or LinuxRT_x64 subdirectory to /usr/local/lib/liblvzlib.so on your target. That should be all that is needed although sometimes it can be necessary to also run ldconfig on a command line to have the new shared library get added to the ldcache for the elf loader. With the old installation method in NI-MAX this was taken care of  by the installer based on the according *.cdf file in the OpenG ZIP Tools\4.2.0 directory.

You can also configure a build spec in the LabVIEW project to auto deploy that library, which is mentioned in the linked thread.

8 hours ago, hooovahh said:

Oh wow never heard of this thing, and now that I'm looking at it, it sure seems like trying to solve a problem that has already been solved with state machine templates or State Diagram Toolkit, with an RT or FPGA.

It is very similar to the State Diagram Toolkit, but has so many more rough edges (and that toolkit was rough). As @bjustice mentioned, it's more about the SIL compliance than anything else.

We've deployed it in an application that required minimum SIL-2 certification for some subsystems, otherwise an FPGA + state machine would've been far more flexible and my preferred choice. The SIL modules themselves (NI-935x hardware) operate using custom firmware on an FPGA, and can operate entirely independently of the cRIO. The FSE compiles the state diagrams into a bin file, which is then uploaded to the SIL module which the firmware then reads and executes, handling I/O, timing, and state transition logic. The I/O can also be configured in passthrough mode, and is then accessible using the scan engine.

My main problem with it is it's just so damned buggy and unpolished. I wrote a feedback thread about it on NI's forum, but haven't seen anything from NI since, much less an updated version (current is version 2018).

It really did feel like it was pushed through for certification (presumably for a large customer) - it's only ever seen two release versions. I guess each release needs recertification for SIL compliance which costs time and money, but I think there are enough bugs and errata in it to justify at least one more release.

Apologies for derailing the thread, @Neil Pate - did those instructions help with the screen calibration?

Looks like that info was taken from this link: https://forums.ni.com/t5/NI-Linux-Real-Time-Documents/Touch-Screen-Troubleshooting-NI-TSM-1015/ta-p/3537931?profile.language=en

Hi Neil,

The TSM-101x calibration issues have caused me no end of problems. It'll lose calibration if the USB cable is unplugged and plugged in while the cRIO is on. It'll lose calibration if you run the calibration utility twice in a row. It was impossible to calibrate at all running on an older version of CompactRIO drivers (I think 18.0 didn't work, but 19.0+ does). I've raised all these issues previously but only get back the same set of KB articles, and they don't solve anything - manual edits to the 99-calibration.conf file don't work, or simply cause the screen to go black.

The only reliable solution I've found was from distributor support (not direct NI support - that doesn't exist any more). It uses a different calibration program called gCal. Again it's very command line based, but at least it works. Copied and pasted from the support email:

Software stack:

• NI CompactRIO 20.0

Reference:

• Touch Screen Troubleshooting - NI TSM-1015

Pre-work: (login with SSH and run the commands below)

• Remove xinput_calibrator
  • opkg remove --nodeps xinput-calibrator
• Install bzip2
  • opkg update
  • opkg install bzip2

Install Penmount 6000 USB Drive for Linux (X11): (login with SSH and run the commands below)

• Check the X.Org version
  • export DISPLAY=:0
  • xdpyinfo | grep version
    • X.Org Version should be 1.19.6 in 20.0 stack
• Install Driver
  • wget https://www.salt.com.tw/tw/wp-content/uploads/sites/2/2017/10/PenMount-Debian-9_32-64bit_driver-v4.5.7_R6.tar.bz2
  • tar -xjf PenMount-Debian-9_32-64bit_driver-v4.5.7_R6.tar.bz2
  • cp pmLinux-Debian9/x86_64/24.1/penmount_drv.so /usr/lib/xorg/modules/input/
  • chmod +x pmLinux-Debian9/x86_64/*
  • cp pmLinux-Debian9/x86_64/* /usr/sbin/
  • pm-setup -s
• Reboot the cRIO
• Start calibration
  • export DISPLAY=:0
  • gCal 4

Another thing you might try is swapping the USB cable for a different one. This managed to fix up a calibration issue in one of our systems.

Sorry for the rant at the start, but this has got to be one of NI's most poorly supported products (except for maybe the Functional Safety Editor - that's built on the bones of NXG, and we know how that turned out).

Here's a dropbox link: https://www.dropbox.com/s/7ey5wngm42eic9g/TDAQ750.zip?dl=0

Thanks for that. I did a quick test and it looks good. I'll report back if I find any problems. Any ETA of when the fix will see a release?

I just ran in to this exact bug today (empty array output when no delimeters found). After a bit of testing, I'm confused as to what the expected output of the function is when Ignore Duplicate Delimiters is set. It certainly differs from my expectation!
 
Here are a few test strings I tried, with my expected output vs the actual output. All tests used comma as the delimiter, and have ignore duplicate delimiter set true.

 
Test Input          Expected Output          Actual Output
string1,string2     {"string1", "string2"}   {"string1", "string2"}
string1,,string2    {"string1", "string2"}   {"string1", "string2"}
string1             {"string1"}              {}
,string1            {"", "string1"}          {}
,,string1           {"", "string1"}          {}
string1,            {"string1", ""}          {"string1", ""}
string1,,           {"string1", ""}          {"string1", ""}
,string1,           {"", "string1", ""}      {"string1", ""}
,,string1,,         {"", "string1", ""}      {"string1", ""}
,                   {"", ""}                 {}
,,                  {"", ""}                 {}

As far as I can tell from the System Exec VI help, this isn't possible:

If wait until completion? is TRUE, standard input is available as input to the command and standard output and standard error are available when the command finishes running. If FALSE, the command runs in the background and its input and output are not available.

That said, it should be possible to redirect WinSCP's stdin and stdout with the use of a DLL wrapper. An article on Code Project titled "Redirecting an arbitrary Console's Input/Output" describes just this.

If SCP/SFTP is what you're after then an external FTP library such as libcurl might be of use. Again this requires DLL calls (and is probably more complex to implement).