Tim_S

Are you using the host key? (I think VirtualBox calls that host.) By default it's the right control key.

Thanks!

Is there supposed to be a 2015 NIWeek_03... file?

Thanks for adding the link to the NI site. Google didn't pull that one up.

For anyone else who may run across this...

The PC is Win7 64-bit. We're using LabVIEW 2012 SP1 32-bit. I was creating a configuration screen including entering an ODBC database name and login information, selecting a table, and selecting columns in the table. There are VIs with LabVIEW to get a list of tables and a list of columns. The challenge was getting a list of ODBC databases. Google brought up a registry entry containing values of the ODBC connection.

This does not pull up the information in the registry entry referenced. The reason for this is here and here. Windows redirects the 32-bit application to a different registry key. The second link includes how to bypass the registry redirection and further link in which registry entries are redirected.

The other bit that was biting me was setting up the ODBC connection. We were going to Control Panel->Administrative Tools->Data Sources (ODBC) to configure a SQL Server database. This is where I went to on my development machine to setup a MySQL database and did not have any issues. The SQL Server setup tested OK in the ODBC setup, but was producing the message, "The specified DSN contains an architecture mismatch between the Driver and Application" when tried to connect to the database in LabVIEW. The message was tracked to this article, which indicated we needed to run "c:\windows\system32\odbcad32.exe" instead of the ODBC configuration in the control panel.

Note that I only had to run the odbcad32.exe for SQL Server and not MySQL.

Another option is to convert the array of cluster of... to a cluster of cluster of... This would let you set the values for each control independently. If you need to scroll through, a placing a scroll bar the value of which is used as the top index in your array of elements to populate the cluster of clusters with. This is quite code-intensive, but works well.

I had another thought about using the Mouse Down? event, determining if the drop down of a combo box was clicked, changing that to a right click, and generating the appropriate menu... then realized that wouldn't work for typing in a value.

I think I have this fixed. Tried a compiled version of the transport library; this worked without issue. I made the timeout changes, which did not seem to have an impact on performance. I then recompiled everything (the server-side code is used in multiple applications on the system); the delay I was seeing with the one message/response went to expected amounts in tests. I've been waiting to test this with the whole system up and going; unfortunately, we've been battling drive issues that are stopping everything else. Can't definitively say it's fixed. Can't point to a smoking gun.

I'm appreciating this forum and the people on it right now.

Installed the second time tried. Not sure what happened the first.

While this is unlikely to be the problem, is there a difference in the network connections in how A and B are connected to the server? Is one directly on the same switch, and the other further away?

All of the applications are on the same PC, so no network switch.

Increase your 100 ms timeouts (and your 10ms listen)  to 1 sec.

 

Also. Try the Transport examples and see if you get the same problem.

Extended the timeouts on the server. Not sure what I was thinking by setting those so short.

Having some trouble getting the transport.lvlib installer to work. I'll have to poke at that to see what's up while on the long haul out of India.

I really do appreciate the responses.

I've run awry of Nagle before. This doesn't feel like that's the issue, but I tried disabling on one end, the other end, and both ends (yea, I'm not 100% on how Nagle gets implemented). Like I said, I did see an improvement, but not the whole solution.

There's no loop to the client; it's open connection, send message, wait for response, close connection. I'm sending binary data in some commands and responses, so I'm prepending the message length. Each side reads the length first. This is akin to the Data Client and Data Server examples, but I'm sending both length and data over one TCP write instead of two.

I went back and looked at how Immediate works. I remember having issues with missing/incomplete messages when I tried using it in spots during initial server-side development, but how I was trying to use it escapes me.

Put together a quick summary. Didn't put in the Nagle VIs, which I currently have on the server side only. Quick summary of client.vi Quick summary of server.vi

I've got an issue that I'm hoping someone has seen before. Any thoughts would be appreciated.

I have three applications, all written in LabVIEW 2012 SP1 running on Windows 7. The first is a server application. The other two are clients to the server. TCP is used to talk between the client and server applications. Both clients use a common communication library for the server application. All applications are on the same computer. The network address is "localhost".

The first client, let us call it Client A, has no issues. Messages sent and received are 'immediate'. This is an application that has been about for a couple of years.

The second client, let us call it Client B, is new. Most messages sent and received are immediate. One message takes 3-5 seconds longer to get a response. I went back in to the server application and timed how long it takes to perform the actions from receipt of message to response; this is <30 msec. Wireshark confirms the response to the message from Client B to server takes 3-5 seconds to occur with no TCP transmit errors. I've disabled nagling on both ends with some reduction of a second, but that still leaves 2-4 seconds when there should be milliseconds.

Going back to my development PC, I setup a small test VI to just perform the messages (no overhead of other code). I see the same behavior over the network to the server application as with Client B.

The messages are mostly small (less than 100 bytes). Similar sized messages/response to the one that is problematic with Client B do now show the same delay issue.

I'm at the end of a project when we're looking at cycle time for production machinery. This message is sent 10 times during the test, so I've got 30-50 seconds of cycle time I'm trying to kill with just this item alone. I will find a work-around if I can't figure it out quickly, but I would rather solve the problem on this job as it will come back on the next.

This is a bit large to post. I've not been able to devote time to shrink it down to an example.

If you're going to Matlab and Excel, a CSV file would be a better choice. Also, I'm not sure the way you've written the TDMS will do what you want; I believe it will concatenate the PSDs into one long waveform.

It sounds as if you don't know how to do the task independent of programming language. If that is the case, I would recommend getting in front of a whiteboard (or piece of paper, napkin or whatever) and write out the pseudocode of what you want to do. Once you've done that, try implementing it in LabVIEW. If you're still having problems, or are having something specific you're not sure how to do, post what you have here.

Some of what you need to decide/define is what is a uniform color and what is a bad pixel.

You need to answer the questions of how much data are you producing and what is going to happen to it. For example, is it going to another piece of LabVIEW code? Is it going to someone who is going to produce a report in Excel? Is it going to the guy in quality control who swears by Minitab? For quantity, is this going to be twenty readings over a few seconds or six months of data taken every millisecond?

TDMS produces a small binary file. I've run across non-LabVIEW (C? VB?) code to read a TDMS file, but I can't say I've seen it as an option for most applications (NI does have a plugin for Excel on their website). If you need something more portable between application, a CSV file is almost universal but will be larger.

I miss SVN. Unfortunately, after two years of our IT person (note the singular) trying to get the old SVN server to work with our new network (new parent company) when he could, it became apparent it wasn't going to happen and I needed something file based (due to network permissions and said IT person's time). So I've been using (or perhaps misusing) Mercurial since. I admit that I do like the Hg Workbench.

Looks like there is a discussion on this over at the NI forums.

It is possible to duplicate the Win7 XP virtual machine.

The hardware discussed is cDAQ hardware, not cRIO.

DOH! I shouldn't be answering questions before the caffeine drip has kicked in.

That kind of question is tricky, if not impossible question to answer without knowing a lot more about your system and implementation.

Can you get data from two cRIO chassis to one PC? Yes. I'm not sure how to do so through the MAX/scan engine as my requirements didn't lead me that way. Offhand, the requirement for "a reading once a minute or so" would lead me towards shared variables instead; I don't recall if shared variables were available in LabVIEW 8.5, though.

RS232 can be from +3 to +15 volts, to -3 to -15 volts (6V pk-pk to 30V pk-pk... see Wiki article). Issues with RS232 are usually mismatch of serial port configuration between the two ends or mis-wired/broken cable.

I ran into this same issue recently. It happened right after I added a DVR containing a typedef to the private data of one of my classes. Do you know if you did anything like that beforehand? What do you think fixed your code before and after the rewrite?

I had enable debugging turned on for quite a while, so it's possible that could have broken things and I wouldn't have seen it. The original code has one DVR of an object that gets passed into multiple loops. The rewrite eliminated that DVR and creates multiple objects for each loop. This seems small initially, but is a huge difference in the code. (This was a decision made after spending some time trying to comprehend the Actor Framework.) There was a lot of copy/paste from old to rewrite; I've fixed code by just copying it to a new VI before.

I believe I had several files (not necessarily VIs) that have become corrupted in some fashion. I have had other projects that would compile, but displayed behavior akin to pushing a doorbell and the house turns green. One project I fixed by performing copy/paste into a new project that is (at least to me) identical in every way (file names and all).

NI tech support is still looking into this issue along with R&D. My last email to them was to send pre-build, post-build, icon and custom configuration files. The pre-build deletes the contents of the temporary build directory and the post-build moves the temporary build to the final directory.

Does this happen at the very end of the build or when it starts?  I've recently had a strange build error, unfortunately i didn't right it down, but it would occur at the very end of building an application.  

I tracked it down to a "read only" file SEH-RTEH-errors.txt located in C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2013\errors\

 

For some reason after every build this file was being set as "read only" and the build would not complete unless i manually unset this file back to non Read Only.  In the end i had to write a script that i run before i build now.

 

I have no idea if this helps with your issues but this was a strange one and thought i would share.

This happens in the middle of the build as the status shows processing each VI in turn.

...a dodgy door handle.

At first I read that as doggy.

Update...

I've been working with NI tech support to try and resolve the error. I trimmed my code back to a splash screen before the issue went away. I've waved the dead chicken and NI R&D has been looking at what's going on. In between emails from NI, I started rebuilding the code from the ground up with a lot of copy paste and some changes with the benefit of hindsight. I've built back up the application to nearly the same functionality and have not had the same issue when compiling. While I have made some changes, I've had an issue with a different piece of code that appears to be corruption in a class, so I'm highly suspicious I have the same issue with this code.

Lessons (re)learned:

1. Compile often

2. SCC

3. SCC

4. SCC

Not a long shot at all, I've seen this plenty of times and I know others that have too.  Here are several links:

 

Looks like it was a bug that was fixed in 2014.  When ever I see it I just close LabVIEW completelly, usually resulting in an error on close, with a soft crash of some kind.  Then re opening the project and hitting build before running the VI usually results in a normal build.  There was also a VI posted by a user somewhere on the NI forums that replaced a VI in the build process that fixed this.  I am not a fan of replacing system VIs so I recommend the restart of LabVIEW.

I appreciate the links. Unfortunately, I've tried all of the settings referenced without success. Clearing the compile cache and rebooting the PC didn't help either. My company is in the middle of moving offices, so my changes of getting the LabVIEW 2014 disks from IT are zero.

Sometimes this error message could occur if some other code in the project is broken. Very often it is a class VI that is not actually used in the main code (say a test VI that has been broken as the API changed, and the dev was a bit too lazy to go back and re-run all the tests).

 

When I get these errors I start pruning the main VI until the build works again, however this is very timeconsuming (and frustrating process) and I would say that most of the time the error is related to one of the recent things I changed.

I have some libraries with templates (.vit files) that are part of the project. I will have to look at this.

This is a long shot, but hoping someone here has run across this issue. I am trying to build an executable and keep getting the following message:

An error occurred while saving the following file: <file name here>

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_EXE.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi -> AB_UI_Frmwk_Build.lvclass:Build.vi -> AB_UI_FRAMEWORK.vi -> AB_Item_OnDoProperties.vi -> AB_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Cannot save a bad VI without its block diagram.

I check the VI and it is not broken. I've had instances where opening the VI then performing the build works, but it does not for this issue.

The only way I've managed to build the application without error has been to set the Enable Debugging flag. I'd rather not have this set, so I've been playing with settings of all kinds (Additional Exclusion flags, setting so block diagrams are kept, etc.), clearing compiled cache, mass compiling, binary compiling... I'm pretty sure NI tech support is going to have me wave a dead chicken next.

One of the odd things I've run into: If I go into the build properties, then changing the reported file's source file settings so that the block diagram is not removed and then reattempt the compile, then I will get the same message with a different file. I can do this for the new file name which leads me down a rabbit hole of files until I start getting to files in the user.lib. I stopped when I got to a VI template file that is part of a lvlib used in the application (the .vit is not used anywhere in the project).

Any thoughts and suggestions (particularly those that keep me from summoning the elder gods) would be greatly appreciated.

I run into this in source (without the AF) and in executables. I put messages throughout the code that go to a debug UI. This may not be able to see all values when the code is running, but it doesn't change the timing of code running at full speed. Since the debug UI displays based on a flag in a configuration file, I can leave the screen in an executable for when I remote into a computer and try to determine what the customer's issue is.