hooovahh

Don't click See my Activity, just on that page you can enter a message, attached image as an example.

When signed in if you click on your profile in the upper right corner and go to Profile you'll see your page. Here you'll find your feed that others can view, and subscribe to follow. I believe in the last rounds of forum updates the simple status update was turned into a more facebook like page with content you follow and posts you've made.

I've wanted this feature on several occasions. I had a discussion on LAVA about it a while ago that I can't find and the suggestion by Darren was to use the VI analyzer to find when subVI terminals weren't wired...he clearly didn't understand what I was requesting. So in my project today as a lone developer I probably have 10-20 VIs that I could use this feature on if it existed. Instead I'm usually forced to do something like set the default value and check against it. For doubles this isn't a big deal, I just set the default to NaN and check for that. Arrays I look for an empty array, strings I look for empty strings. But integers I don't have a good solution for and will sometimes make the input a double, and set it to NaN. Admittedly in my cases most could be resolved if wanted to bother with polymorphic VIs. So I may have something like convert a typed cluster to a string that is human readable. But I also might want to convert an array of those clusters into a scalar string. So I'll have a VI that has both the scalar and the array of clusters and look to see if the array is empty, and then operate on the scalar cluster instead. Most examples I have are derivatives of this. Having a path, VI refnum, and string input is another one I remember. If the VI refnum is valid perform some VI server call on it. If it isn't but the path control isn't empty then open a VI reference then operate on that. If the VI refnum is empty, and path are empty, do a open VI reference on the VI name. There are a few advanced string functions I wanted to create for getting string subsets. Where things like unwired inputs meant the rest of the string, mirroring some of the LabVIEW primitives. Of course in these cases I usually have a numeric input that has the default set to -1 and then have the check for <0 and if so do something special. This one is pretty common for getting subsets of other data too like arrays or circular buffers. I would use this function if it existed to make more intuitive code that mirrors some of the palette functions today, and I'd use it to help skirt around the weaknesses of polymorphic VIs. Once you realize how the delete from array function works, you like the fact that it behaves differently when some inputs are unwired. I'd like my code to have similar abilities some times.

Very interesting, all the GIFs I was testing with had the same delay between all frames. Wonder if NI this could be an issue brought up to NI and have a CAR assigned if it is related to short frame length, or varying frame length in the images.

So what I suspect here is that you were using the TDMS write over and over again but the buffer never caused a flush to disk, and you never explicitly called the flush function. Then the program crashed and no file was written to disk. If your file did at one time flush to disk then you'd have some data to look at. If you have a file but it has an error on open, then you might be able to still pull out chunks of the file and recover some of the data. I tend to have a logging module (actor) that will periodically flush to disk, then check for fragmentation, and close, defrag, and reopen the file if it gets fragmented. This is in parallel to the test running so data will pile into a queue while this is happening. This helps make TDMS a bit more robust, because as you found if you have the whole file in memory and then the system crashes, or there is a power outage, then the file is lost. Flushing to disk periodically help keep at least some of the data.

Thanks Mads for teaching me something new.

I sent Michael an email.

Settle down buddy, posting the same question in 3 threads isn't very polite. As far as I know you can't use DETT on EXEs. EXEs don't contain source, or the block diagrams, and many front panels are missing. This makes debugging them very difficult. If the application is stable in source, it would be very odd if it wasn't stable as an EXE. Apparently you can and Mads has the details.

It's not that they expect it to break, they just would like one less thing to worry about. Maybe for other industries it wouldn't be a big deal, but I doubt I could get my boss to agree to used equipment in a test system. Maybe for basic prototyping, but for that NI is pretty good on loner equipment. Sorry I can't really help.

So with a little help, I was able to upgrade the RT Linux part of the system to have LabVIEW 2015 SP1, and with it I was able to add the target, connect, deploy code which ran bash commands, and got the result. Still no UI and there is a good chance that just wasn't included in the package anyway. And still no way to install more software through MAX. After you install the OS using the NI provided ISO, boot up the VM using the network adapter Host-only. Hopefully when it boots it will show the IP address and it can be pinged from your Windows OS. Using Filezilla connect to using "sftp://<IP Address>", username "root" and blank password. Navigate to /usr/local/natinst/labview and delete or rename the lvrt file, and delete the symbolic link liblvrt.so.15.0 (the file can remain) I wanted to upgrade to 2015 SP1 so I transferred over the lvrt and the liblvrt.so.15.0.1 files from the following directory: C:\Program Files (x86)\National Instruments\RT Images\LabVIEW\2015sp1\Linux\x64\ Next we need to set the permissions on these two transferred files, so in Filezilla right click and set the properties of these newly transferred files to 755. Next we need to recreate the symbolic link we deleted earlier. So using putty log into the VM, and navigate to the /usr/local/natinst/labview folder and execute the following command. ln -s ./liblvrt.so.15.0.1 ./liblvrt.so.15.0 Then reboot the controller. Then in LabVIEW 2015 SP1, create a new project, and add a new target or device. Specify it with the IP address, and specify the type as a Real-Time CompactDAQ >> 9135 (this is a controller with x64 RT Linux). You should now be able to connect, and deploy, and run code to the RT system. I tested it running the system exec "ls" and it listed files as bash should. I've also been able to deploy code that uses TCP, UDP, WebDav, Network Streams, DataSocket, and VISA functions so these libraries are installed with the ISO, but no DAQmx, not that this VM needs it. In my mind the most benefit is from being able to use and call into 3rd party libraries and test deploying network code.

I'm afraid the resale market on NI stuff is pretty poor. The only real suggestion I have is ebay, but things don't sell well there, just because its not the type of thing most people are in the market for often, and most also consider the warranty of new equipment important.

On my Linux RT setup I've seen several issues with TCP connections just getting lost, glad to hear I'm not the only one. For now I've just added a retry which will close, and reopen the connection and issue the previous request and wait for the reply. I've also added code to periodically send a request and get a reply even if I don't need it, just so I can keep the connection alive, and close and reopen it if the connection when down. In my setup I'm talking to 4 pieces of TCP equipment, through a router on one NIC, and on the other talking directly to the Windows PC. The error I've seen on the RT side is 63, connection refused by the server, which makes me want to blame the equipment a bit but its all new, and it is 1:1 like your setup. I haven't figured out the problem, but the retries are working and add a bit of jitter but is acceptable based on the timing needs of the equipment. I'm not saying there is something wrong with the RT Linux TCP stack, but I don't really have much to go on.

This is not the case in VirtualBox. I installed it on a fresh VM with no OS. I also tried the upgrade method starting with Pharlap but the results were the same in both cases. During the install it complained twice saying something like this isn't supported hardware and it might not work, do you want to continue anyway? And I just said yes until it asked to remove the CD and boot normally.

Yeah I tried the "upgrade" route and you're right, it isn't an upgrade and wipes away the OS. Still you can have a RT Linux VM. Just no MAX or installing software...and at the moment you can only develop for it in 2015, but putty, networking, and package management works.

I didn't include the HTML file in my zip because the Publish will create it, and then open it in the default browser. It's pretty self contained and has several improvements, but the core basics are the same. Glad you got it working, and glad I finally got around to testing it with a webserver.

What I did (not an expert BTW just like playing around) was from the XAMPP I clicked Explorer and searched for Dashboard. Notice that is the folder you are in in your browser. From there I found the root of my server was at: C:\xampp\htdocs So I ran the command mklink /J "C:\xampp\htdocs\Test" "C:\FP Publisher\www" This makes Windows create a folder called Test which points to the www folder where the webpage is actually created. Then from a browser you should be able to go to http://192.168.1.94/Test/Demo HTML5 Page.html and see the page at C:\FP Publisher\www\Demo HTML5 Page.html. Even if the VI isn't running you should see the page with static data. Then run the VI then refresh the page. Obviously update the path in the mklink call to be the location on your disk to where your www folder actually is.

In LabVIEW you can add the target by specifying the chassis type and IP address, but when you go to connect it complains about software compatibility issues. This is because that ISO includes LabVIEW 2015 (non SP1), but I don't have the non SP1 version installed. Presumably if I did I could connect to the target in LabVIEW and deploy code. Other attempts at adding the target are met with odd errors from MAX. If you try to add the target manually in MAX by specifying the IP address it says it is unable to initialize a connection. If you use the Troubleshoot Remote System Discovery and specify the PXIe-8135 (which my VM thinks it is), then it will search for remote targets, and the simple error handler comes up complaining about releasing a queue generating error 1. I suspect you are right in that this OS is intended to be used with the Comm Suite and MAX isn't supposed to be able to find the target. So installing additional software through MAX likely isn't possible. But writing code and deploying to it might be possible if you have LabVIEW 2015. The software installation wizard appears to be built into MAX and not a separate application that could be called specifying the IP address of a chassis. So unless there is some other way to get the system recognized by MAX, or some other method of installing software by side-stepping MAX then this might be a dead end.

So I've never actually tested this until today but I got it working without too much of an issue. The older version (the one before my posted edits) didn't support remote systems very well. You could only access the page from localhost. In my version the Publish.vi has an input of what the host IP should be and if it is left blank it is localhost, but on my BD I have the unwired PCs IP address. This address goes in the page and basically says where to get the web socket data from, and is used in the HTML JS Template.vi which creates the HTML file. To access this page from a remote computer I've been using SMB file share in Windows (and mapped network drives for the RT) which admittedly is a bit odd and a web servers should be used instead. This is using two different protocols, one to get access to the HTML file, and the other to use websockets to share the data. I worked on improving that this morning and it worked. I installed XAMPP on my Windows PC. I then started up Apache (which is probably all that is needed) and then made a symbolic link, pointing a "Test" folder from my Apache to my www folder from the example. I could then navigate to http://<My PC IP Address>/Test/Demo HTML5 Page.html on my local machine and the page came up with updated data. I then put my Android phone on the same wireless network, went to the same address in Chrome and everything worked. Drop downs, button clicking, etc. So I think the trick is 1) You need to be using my edited version for access on anything other than localhost, and 2) You need a way to get access to the HTML file and the easiest for me was an Apache web server. It would be really neat to see if I can also install Apache on the Linux RT system I have and also navigate to a web page that way. Although reading through your post again I see you had it working on a remote computer so that means you already have the localhost issue fixed.

This behavior is the same on 2015 SP1 and 2016 which are the two versions I have installed, but I know I've placed loading gifs on splash screens from 2011 and newer, and the speed wasn't effected.

This is simply not true. Download the VI posted in this thread and you'll see the two GIF that have the same number of frames are at different rates. Recently a user also posted talking about having GIFs on buttons and I was able to make a GIF with a 400ms delay in it and put it on the front panel of the VI and it delayed as it was supposed to.

I have used both. Sometimes "Canceled" and some times "Valid Data". I hadn't really thought about it but I'd say the majority of the time that the data isn't valid, an error will be returned of some kind.

Well the report generation toolkit could be much better, and has several functions from older revisions of office that still work but are inefficient, and limiting. That being said I usually end up doing a combination of using the report generation functions, and then use the Get ActiveX Reference, which allows you to do as you please. I think you can even write companion classes that could extend the functionality of the RGT. So I wouldn't say the tookit should be avoided, just know its limitations, and don't expect that you only need the functions provided. Sorry for my assumption that you were using it.

Well as mentioned by olfenr there is a solution to a Linux RT VM using an NI provided ISO. Posted here is an ISO apparently intended on upgrading the OS on PXI RT chassis, to put RT Linux on them, so that they can then be use with the Communication and Design Suite which presumably only supports the Linux RT variant and not Pharlap/VXworks. You can use this ISO to install the RT Linux OS into a VM made by Virtual Box. After installing the OS and using the username root, and empty password, you can login, and SSH into it. I cannot seem to get the remote target recognized by MAX, so I can't install software, or deploy code from LabVIEW. I've played with the network adapter settings and using Host-Only I can ping the target from my host, but I cannot add the target in MAX. One thing I just thought of but haven't tested, is possibly starting with installing the Pharlap RT OS in a VM, then using this ISO to upgrade it.

I'd find it hard to believe such an old piece of documented code has a bug this big in it, but you are starting to convince me. If you don't get any more help here I'd suggest making a post on the dark side (NI's forums) where their AE's monitor the boards closer, and may assign CARs. They can also sometimes talk to the guy that implemented the feature or function and get better insite into why it might behave this way.

Well the first thing I noticed is you are trying to control Office 2016 with LabVIEW 2015 which the report generation toolkit doesn't support, so it likely hasn't been tested properly by NI. Sorry I've never seen this or have any suggestions other than to try it out with LabVIEW 2016, and the updated report generation toolkit. Of course I realize it might not be that easy since there maybe other dependencies, and setting up a test for this setup might be a huge problem. But I'm guessing you won't get a whole lot of support from NI on this issue due to the documented incompatibility.