All Activity

Most likely a cerebral shortcut with his more involved SQLLite library he has worked on so relentlessly over the years. 😀 There is a good chance that the Windows version of the PostgreSQL library is compiled in a way that supports multithreading calls while the Linux version may not. With the CLN set to UI thread, LabVIEW will always switch to the UI thread before invoking the library call, resulting that all such CLNs are always called in the same thread. With "Call in any thread" enabled, LabVIEW will call the shared library function in whatever thread the VI is executing itself. A VI i

Hi , There’s no doubt about it: modern business is an extremely complex entity. Businesses have to be able to manage the data associated with potentially millions of clients, in addition to the information related to their own business processes and systems, in order to understand their market and clientbase. To unlock the power within so much intricate information and so many systems, successful businesses have begun to rely on advanced business process automation (BPA). What Is Business Process Automation? In the days before computing became an integral aspect of business, busin

Bug described on NI Forum : https://forums.ni.com/t5/LabVIEW/Map-weirdness-on-Linux-RT/td-p/4114641 With video and code. I would be eternally thankful if anyone could try to reproduce on various Linux RT targets with LabVIEW 2020.

If the only way of commanding your camera is through the vendor sdk, bleh. As Rolf wrote, though YMMV. If by chance the camera is supported by v4l2, there you go; shameless self ad.

Data buffer handling and especially callback functions really requires you to write an intermediate shared library in C(++) to translate between LabVIEW and your driver API. Memory management in LabVIEW has some specific requirements that you need to satisfy and usually goes against what such drivers expect to use. They are written with C programming techniques in mind, which is to say the caller has to adhere to whatever the library developer choose to use. LabVIEW on the other hand is a managed environment with a very specific memory management that supports its dataflow paradigma. Ther

I'm confused... what is the connection between SQLite and PostgreSQL?

SQLite is thread safe unless it is changed from the default "Serialized" mode: https://www.sqlite.org/threadsafe.html

I am trying to read images from my Gige camera, but on LabView Linux Imaqdx is not available. So i tried wrapping the vendors Gige implementation. But i had some problems regarding passing handles and the callback function to receive the images. If someone have experience regarding image- aquisition without imaqdx or know a different way, i would be grateful for your suggestions.

It is difficult for me to give good advice without really understanding the project. Some random thoughts: Where are the performance bottlenecks? The first thing I would do is prototype and benchmark the steps and get a feel for what are time-limiting, high-CPU steps. Be wary of designing a complex custom communication pattern "for performance" before you understand what and where the performance issues are. How long does it take to convert your IMAQ image into a DBL array, for example? You might find that effort on a custom queue system is better spent on some other area. Reme

I totally get you wanting to display newer entries first, but surely this is just a presentation issue and should not be solved at the file level? I really think you are going against the stream here by wanting newer entries first in the actual file on disk. It is almost free to append a bit of text to the end of a file, but constantly rewriting it to prepend seems like a lot of trouble to go to. Rotating the log file is a good idea regardless though. Notepad++ has a "watch" feature that autoreloads the file that is open. It is not without its warts though as I think the Notepad++ wi

The target system is for optical coherence tomography. We are pulling 2048 wide U16 arrays from a linescan camera spectrometer from a framegrabber using IMAQ. The line rate is 80khz. The data is naturally blocked into "b-scans" which are ~1024 pixels wide, but we want to increase this in the future. The IMAQ buffers reflect this. So we get a 1024x2048 U16 image every 13ms or 75 images per second. The images are then converted to doubles for processing due to the limits of the LV Analysis library. This means 1024x2048x8bytes = 16MB per 13ms or 1.2GB/s. The processing includes linearization

Looks like you have a few confirmations about the crash in 2019 but fixed in 2020.

Here is a nice one, see my post on NI Forums found in LV2019 SP1, if someone could check LV2020, it would be nice.

What kind of data and data rate?

Only the name is deleted, commits are left untouched. It is actually possible to restore the branch name if you know the commit hash - https://stackoverflow.com/a/2816728 This can be useful if you deleted a branch before it was merged into master, or if you want to branch off a specific commit in the history that is currently unlabeled. Here is some documentation from Atlassian, generally applicable to GitHub as well: Git Branch | Atlassian Git Tutorial Pull Requests | Atlassian Git Tutorial

That is good to hear.

Tangentially, I use Plastic SCM at work (Unity/C# dev), it really hits the sweet spot of easy to use but powerful DVCS. I believe it is modelled on Git but designed to trivially handle many branches.

OK, so deleting the branch on the remote only deletes it from being used in future, it still exists in the past and can be visualised? Sorry I misunderstood and thought that git did magic to actually remove the branch in the past (which would be a bad thing). I know about rebase but have never thought to use it.

The Network Graph mentioned by @JKSH does give you some visualization on GitHub. I personally prefer the visualization in Sourcetree and bash. Here is an example for GitHub - microsoft/vscode: Visual Studio Code The command I use is git log --oneline --graph You can see that branches still exist even after merging. Only the name of the branch, which is just a fast way to address a specific commit hash, is lost (although it is typically mentioned in the commit message). That said, some branches can be merged without an explicit merge commit. This is called "fast-forw

My informations from inside NI is that this is largely untrue. NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support 😮 I don't have much details but different sources corroborate this.

You guys always have the best information/ideas... Thank you all... Since I really like the new entries at the top of the log file, and my major worry is that the file gets too big over time and causes the the log write to consume too much time I really like dhakkan's approach of checking the file size periodically and flushing the file and saving the data to numbered files.

This is exactly right. A branch points at a commit, and the commit to which it points changes as additional commits are added to the branch. You can reset a branch to point at any arbitrary commit, even one in what you might think of as a different branch, because again, it's just a reference to a commit. Deleting a branch removes the reference with no impact on the sequence of commits. In case you want to make things more complicated, git supports an alternate mechanism to merging branches, where code is "rebased" rather than "merged" so the eventual history looks like a single continuou

As @pawhan11 said, no story is lost when deleting a branch because only the pointer/reference to a commit is deleted, not the data itself. See here for a visual example: https://github.com/ni/niveristand-fpga-addon-custom-device/network The horizontal lines show the histories of parallel branches. The dots on the horizontal lines represent individual commits. The black-background labels are the "pointers" that represent active branches. "Deleting a branch" means removing a black label. "Creating a branch" means attaching a black label to a commit

Started transition from svn to git recently and I might be not 100% accurate there. Branch for git means just an link to a commit. When branch is merged and later deleted no history will be lost, all commits from deleted branch will remain as they were. If You delete branch that was not merged then commits in that branch will not be 'reachable' and eventually be garbage collected - never seen that one yet.

I still don't really get this. I want to see the branches when I look in the past. If the branch on the remote is deleted then I lose a bit of the story of how the code got to that state don't I?