JKSH

Reading through this thread, it appears to me that neither odoylerules nor yourself wanted to start a "My SCC vs You SCC" debate, but you've both ended up talking about specific SCC features in detail. Here's what odoylerules wrote: "...disregarding the SVN vs GIT debate, my main thought was more on the distribution side as SourceForge is just not a good host for things like this. I suggested Github.com, not expecting the maintainers to switched to GIT, but specifically b/c you can import SVN repositories and use SVN commands/clients while hosting the code on Github.com. In addition, github.com provides binary distribution, issue tracking and management from a single unified place. While i read lavag.org all the time, using a forum to track code issues is a very outdated method." Regarding these points, SourceForge provides "binary distribution, issue tracking and management from a single unified place" too, and I see that the SourceForge issue tracker has many entries (albeit not for the past 3 years). It's just that our community prefers a different distribution platform (VIPM), and I'm guessing that many casual users aren't aware of the SourceForge issue tracker. I don't know if switching to a different host (no matter which SCC backend is used) will change this. Anyway, if the main concern was distribution, I think VIPM is superior to any integrated binary download mechanism provided by online repository hosts. I'm not convinced that switching SCC backends will change OpenG's rate of contribution either. Is there a list of of existing contributors? So far I've only been able to find the list of authors for individual VIs embedded in the front panels.

Mm, you're right. Requirements prioritisation and firm, systematic management is the way to go. I've been spoilt -- our manager used to do the same work as so he defers to us for timeline estimates calculations, and most of our customers have been reasonable with their expectations

Sometimes, users ask for things without fully understanding the complexity involved. If you're asked, "Hey can you add this to it..." you can reply, "Yes, and it will take X days and/or Y dollars to do it properly". If they pressure you to do it faster/cheaper, you need to make a judgement call -- should you should do as they asked, or should you try to change their mind? If it's not truly urgent, you could explain that shortcuts will jeopardize the quality of the code and make it harder to make improvements in the future. Cleaning up your code could make it easier to get it stable, simply because the code becomes easier for you to follow. The easiest starting point it to identify and delete code that doesn't do anything useful. I would get rid of those disabled/abandoned bits. Another example: The pink wire at the bottom of the DAQ loop is unused and should be deleted. Here's a starting point: Better Separation of Concerns. One component should focus on doing only one thing, and other components should not share its job. This makes it easier to reuse the component in other projects. It also makes it easier to identify where a change needs to be made when updating the code. For example, the DAQ loop should indeed be in charge of doing DAQ, but it shouldn't be responsible for reading/writing settings files. Avoid duplicating code. For example, in the DAQ loop, "Safe Stop" and "Timed Safe Stop" have exactly the same logic. See if you can find a way to merge them. More comments within the code, to describe what's going on. What do the various boolean wires mean? I'm not sure what you're asking, and I can't run your code. I recommend creating a new VI, put an Elapsed Time express VI in a loop, and experimenting with its inputs and outputs. See post #4 (Hooovah posted some sample code). Reading http://zone.ni.com/reference/en-XX/help/371361M-01/lvexpress/elapsed_time/ could help too.

I don't suppose you have access to one of the shiny new Linux RT cRIOs that have a mini-DisplayPort for built-in GUIs? (cRIO-9030) I wonder if that works. I've built a program for a cRIO-9030 which uses control/indicator property nodes and an event structure, so that means the references exist there. The cRIO is now with the customer though, so I can't experiment with it anymore.

Perhaps you could let the user toggle between Debug mode and Release mode? Debug mode performs checks and flashes big angry warnings if a violation is found; Release mode assumes that the developer has already combed through their code using Debug mode, so it skips the checks.

I haven't used LabPython before either, but I do know that Python 2.x is not compatible with Python 3.x. I'm guessing that the function called "_Py_ZeroStruct()" exists in the Python 2.x DLL, but not the Python 3.x DLL. Try installing Python 2 instead.

If you want an off-the-shelf product, you'll need to find one that understands the raw records. What format is your records stored in? I've done one TestStand project, and my client was happy to use TestStand's built-in reporting functionality. We configured the station such that each test produces an ATML file for easy viewing, and also inserts the data directly into a Microsoft SQL Server database for easy querying and processing.

I'm not entirely sure what the table is trying to say. The note says "...the column titled 'Windows 10 64-bit (Using 32-bit Software)' indicates the first version of 32-bit software that will run within the... (WOW64) emulation layer", and the table says: Windows 10 64-bit (Using 64-bit Software) does not support LabVIEW 2015 32-bit Windows 10 64-bit (Using 32-bit Software) supports LabVIEW 2015 32-bit Windows 10 64-bit (Using 64-bit Software) supports LabVIEW 2015 64-bit Windows 10 64-bit (Using 32-bit Software) supports LabVIEW 2015 64-bit I take #2 and #3 to mean that 64-bit Windows 10 supports both 32- and 64-bit LabVIEW 2015. I'm guessing that #1 means you can't run 32-bit LabVIEW without WOW64. I'm guessing that #4 is a typo, since you can't run a 64-bit application in a 32-bit environment.

Can you please clarify your goals? What you want to achieve by using remote functionality? In your original post you said "I'm trying to exchange data between two executable. The way I was using in the past was VI server." However, you don't necessarily need VI Server to exchange data. Also, you can design your programs to use shared variables for remote control. Let EXE1 can send a command to EXE2 through a shared variable. EXE2 just needs to read the command variable, and perform the action that you want.

You'll have much better luck posting to http://forums.ni.com/ than submitting a service request. (Twice before, I tried to submit bug reports using service requests. The staff who was assigned to me started off by asking very simple questions which were already answered in my original post. Since then, I've posted all my reports to the forum, and get good outcomes)

In my experience, if you post bug reports at http://forums.ni.com/ you'll catch the attention of NI staff and there's a good chance they'll open a CAR (especially since you have instructions and workarounds).

Same for me, with LV 2014 SP1. Alt+Tab and clicking work fine. I can also use Ctrl+E to switch between the Front Panel and Block Diagram. Hallelujah (Windows 8 does that too, by the way) Now if only Windows would prevent LabVIEW from bringing all of its windows up to the foreground as soon as I activate a single LV window...

Clever. The key ingredient I missed was the ability to make the TCP Read node block until the specified number of bytes arrives -- this definitely simplifies things.

Network streams are built on top of TCP. It provides a simpler interface than TCP for streaming data point-to-point, at the cost of losing the ability to listen for multiple connections. It's nice to be able to dump an array of doubles in one end and get the same array out the other end, without having to search for data boundaries and reinterpret bytes. We are currently developing a system that controls and monitors a pilot plant, using CompactRIOs and CompactDAQs connected to a central PC server. There are a large number of I/O points, a number of which need kHz sample rates. The cRIOs and cDAQs use network streams to transfer the waveform data to the server for logging. Also, our customer wants to allow an arbitrary number of client PCs to view the logged data. The server accepts requests from a client via raw TCP, taking advantage of the TCP Listener function. Once a request is received, the server sends a unique ID to the client to establish a network stream for transferring the waveform data.

Use a black marker to write outside the cylinder?

I suggest posting to http://forums.ni.com/ -- I don't think there's that many official NI eyes at lavag.org.

Did you pick one of the options at https://lavag.org/topic/19288-html-file/?p=116346 ? You could also buy LabSocket: https://lavag.org/topic/17164-new-release-of-labsocket-the-easy-way-to-extend-labview-to-the-web/ I don't quite understand what you wrote, sorry. Please give a detailed description of what you did, and post screenshots of what you saw.

Ah, that's a big one. Forgot to include it in my diagram.

This article should provide a helpful perspective: http://www.ni.com/newsletter/51675/en/ C was my first programming language. Then, I learnt assembly for 2 microprocessors, then C++, then LabVIEW, then TestStand. Learning C helped me to understand memory management, which gave me insight into how LabVIEW does buffer allocations behind-the-scenes. TestStand has a very C-like structure, so knowing C made it easier for me to learn TestStand. Learning assembly (together with digital logic) helped me to understand how software translates into hardware steps, which gave me insight into what the LabVIEW compiler needs to do behind-the-scenes, and it made it easier for me to learn the FPGA module in LabVIEW. Learning C++ helped me to understand OOP concepts, which made it easier for me to learn LVOOP. Note: This is my personal journey to my current state. Learning C (and the other languages I wrote about) definitely gave me a better "intuition" on how to write LabVIEW, but they're not strictly necessary. I don't think it's the most efficient pathway if your main goal is to improve LabVIEW skills. Other people have probably developed the same "intuitions" via other pathways. Note also that I no longer use C or assembly these days. Although they were a good learning experience, I find them too unwieldy for my daily use cases. LabVIEW and C++ are now my preferred tools. I'm guessing that's because the move from C to LabVIEW is a big paradigm shift, so they're simply struggling with a language that's "alien" to their "mother tongue". In fact, I experienced the same when going from C to C++! (They might have similar core syntaxes, but they're very different languages) You might experience a similar struggle when you start learning C, but I highly doubt that it will degrade your LabVIEW skills. After all, LabVIEW is your "mother tongue" ;-)

I also press Ctrl with my left pinkie a lot; I often do Ctrl+Shift+S to Save All in LabVIEW, and even Ctrl+Shift+Tab to navigate my web browser tabs. I avoid stretching into awkward positions whenever possible; instead of leaving my hand in the home position and stretching my fingers out to the left, I move hand and elbow freely to reach the keys comfortably. For example, when I do Ctrl+Shift+Tab, my index finger and thumb can end up above the 'W' and 'Alt' keys respectively. Instead of simply rotating my left wrist counterclockwise, I also move my elbow away from the keyboard to reduce the amount of rotation needed in my wrist. I agree with Gribo and recommend that you see a physiotherapist to assess your situation and come up with a treatment/rehab plan. They can also identify any sub-optimal movements you might be making with your wrist/hand/fingers, and teach you how to correct those.

That's the defining feature of an Event Loop: The loop only iterates when there's an event to handle. When there are no events of interest, the loop sleeps to conserve CPU cycles. As drdjpowell explained, you can. Just input a loop period into the event structure's Timeout terminal. (Note: This means you won't have an Event Loop, but a hybrid event + polling loop instead.)

You have two options: Create a LabVIEW Remote Panel: http://www.ni.com/tutorial/4791/en/http://www.ni.com/tutorial/4791/en/ , OR Set up a Windows Remote Desktop connection, to let your supervisor log into your PC: http://windows.microsoft.com/en-au/windows/connect-using-remote-desktop-connection#connect-using-remote-desktop-connection=windows-7 Option #1 is more secure. Note: Option #2 doesn't use a HTML file, while Option #1 does. However, you don't convert your program into HTML. Instead, you create a HTML file to let your supervisor control your LabVIEW program through the Internet. You must still run your LabVIEW program on your local PC.

Hi @jackky, a HTML file contains source code for a web page: http://www.w3schools.com/html/html_intro.asp Who asked you to convert your LabVIEW program to HTML? Why do they want this? (the reason is important, because it affects how you should proceed)

Yep, one repo per library sounds good. This is a valid solution. It's called "bundled libraries". It works for tiny libraries, where creating release packages (described below) might be an overkill. (I personally don't like bundled libraries because the duplication can make things messy in the long run, but it works) user.lib was designed precisely for this purpose. The fact that the project devs "need to know to check out the dependent libraries" should not be considered a disadvantage. After all, a project's dependencies should be part of the project documentation. However, the project devs should not check out the library. Instead, they should install the library -- install a stable released version, which has been nicely packaged by the library's developers. See the VI Package Manager: http://jki.net/vipm Again, I would not make individual revisions accessible. Project devs should only be allowed to choose from the (small) set of stable releases. Furthermore, a mature library should ideally have a stable Application Programming Interface (API). Newer versions should aim to avoid changes that break compatibility with older versions. This way, you don't need to worry about juggling multiple versions -- just install the latest stable version. Exceptions to the "minimize compatibility breaks" rule are: When the library is in its infancy: It's ok to play around with the API at the start, to figure out the best design. However, it's probably risky for projects to rely on an immature library anyway. (If the library is that new and it's under your control, you could develop the library as part of your project first. Then, when it matures, split it off into its own repo as a standalone library.) When the library has evolved to a point where it needs to free itself from the shackles of old, deprecated functions in order to progress further, or when the burden of maintaining the old functions becomes too great. This should not be a regular occurrence (once every few years, perhaps?)

It's fine; NI themselves published the list: http://download.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf