hooovahh

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.

Oh so sorry, yeah as I was writing that reply I did notice that with the PV so low I'd expect the MV to go really high. The only thing I can say is that the PID sees that the PV went from a low number (30), to a higher number (50) instantaneously, and part of the PID is the derivative meaning predictive changes will occur, based on how quickly the value changes. Even though the new PV is still below the setpoint, the PID sees this fast increase from 30 to 50, and predicts that the next time it is read it will be even higher, and thinks it needs to lower MV in response to that fast change. Again not a PID expert, just what I've observed. In the real world, your sensor shouldn't change that fast, in that short amount of time, and if it does, lowering the MV might be the right response, based on the PID values. ...Of course now that I look at your code again your "D" value is 0. But by changing your "I" to 0 this behavior doesn't occur, so I'd suspect my reasoning is correct, but my specifics aren't.

I just painted the tab with the color brush transparent, starting with the classic tab. Having a picture ring that you need to change the values of isn't a big deal, but it is more code that my solution didn't need.

And not just because Thomas is also a Dilbert fan? Keep in mind that code is still in its infancies. That being said I've been successfully using it on a couple of projects, one with over 1,000 individual front panel objects (really should have worked on implementing arrays), and unlike the other 10 or so solutions for web based control of a VI, it is 100% open source so feel free to make improvements.

I selected the Classic Square Button to start, and then using the painting tool colored the True, and the False values transparent. This button has 4 states (not 6 like system buttons) and painting the two values made all 4 states transparent. But you can just copy the button for yourself. I didn't. If you run the VI you see this shoadowing go away. This is because this shadowing is not part of the UI and is only there to show that an object is on top of another object. You get the same effect if you move any control over top of a tab (not by dragging that places it in the tab) Picture rings, and 2D picture controls in general don't support gif, or alpha layer transparencies. This is why I went with images on the front panel, it is the simplest solution. Otherwise when you have a gif you need to have code running in a loop that will update the static images at regular intervals. With this image that isn't too hard to do because there is a 400ms wait between changing the image but it still adds more logic, and if you only have these 4 states the code is quite simple.

The problem with testing a PID is partially that you don't have the full setup, you are creating a control for your output, but you aren't adjusting the process variable with a simulated model of your environment. Let me try to explain the best I can with my non-academic view of a PID. So lets say you have a valve you want to control with a PID, and it will open and close and let in more or less water through a pipe. So you create a PID and you want to test it without the hardware, which is what you have above. But the problem is when you adjust that valve in the real world, your measured flow will actually change, and that new measured flow will go back into your PID, and then the PID will adjust the output control a little more, which opens and closes the valve more, which adjusts the amount of water flowing more, which is your simple feedback. But in your simulation you are adjusting the value, but your flow being measured (PV) stays the same. It is like the PID is closing the valve more and more, but the flow keeps coming, so the PID closes it more and more, but the flow keeps coming. A better system is to model how the valve and flow relate to one another, and then have your PV going into your PID change, as your output of the PID changes. You have there a constant of 90 as your setpoint, telling the PID "I want you to be 90". Then you have your PV (essentially the flow reading) set to 50 for 2 seconds, then 30 for 2 seconds then 50 for 2 seconds (if the comment is correct). This means your measured flow in my example doesn't change for 2 seconds, so the PID is going to try to adjust the valve continually in the same direction. If you want a good basic example, look at the General PID Simulator.vi by searching for it in the Help >> Find Examples (I searched for PID). It has a simple model where there is a PID that sets an output, and then a plant simulator pretends to be the real world behavior.

That changes things a bit but I think the easiest solution (assuming there is always 4 states) is a tab control with an image in each. Then a transparent button on top of all of them. Attached is an example in 2015. Demo 4 Button Gifs.vi Edit: Back saved into 2011 hope it turns out. Demo 4 Button Gifs 2011.vi