JKSH

3 hours ago, drjdpowell said:

Just for info: my recipe to fix a "detached head" is (using SourceTree)

Shorter alternative A, involving a console:

> git branch -f <real_branch>
> git checkout <real_branch>

The first line forces real_branch's pointer to move from its old spot to your current spot.
The second command moves your HEAD from your anonymous branch to your named branch.

Shorter alternative B, involving a strong stomach:

1. Delete <real_branch> (yes, you read that right).
2. Create a branch called <real_branch> on the detached head commit.
3. (If the original <real_branch> tracked a remote branch) In SourceTree's "Branches" nav pane, right-click <real_branch> and click "Track remote branch".

3 hours ago, drjdpowell said:

(no actual code merge occurs, so this is non-intuitive to me)

If it helps, think of it as merging the commit histories of the 2 branches, rather than merging code. Its formal name is a "fast-forward merge".

3 hours ago, Ratataplam said:

with external usb keyboard, but the result is the same.

You might need to try different models of keyboards. See my previous message: Some keyboards work, some don't.

Also, after you plug the keyboard into your laptop, you must insert the keyboard into the VM (in VirtualBox, click Devices > USB > [Name of USB Keyboard]).

5 hours ago, Ratataplam said:

but when the installation arrives at the first choice option I'm not able to select anything because the keyboards on VM doesn't work

You're almost there. The NI Linux Real-Time Recovery system is incompatible with the VM's keyboard^.

When you reach the prompt, "Do you want to continue? [y/N]", make sure you have a physical USB keyboard connected to your PC. "Insert" it into your VM (on English VirtualBox, it's Devices > USB > [Name of USB Keyboard]), then use the USB keyboard to enter "y". You might need to try different keyboards; I found that:

• Microsoft Wired Keyboard 600 did not work
• Logitech K235 worked

^Earlier, you were able to select "Verbose mode" with the VM keyboard because you were still in the GRUB bootloader, not in the NI Linux Real-Time Recovery system yet. GRUB is compatible with the VM's keyboard.

3 hours ago, Gan Uesli Starling said:

all I find is Math/Geometry/3D Rot (direct and euler) which both take ARRAYS for their input, and a 3X3 ARRAY for it's command... How can I use it instead to deal with a single point (anywhere) relative to the system origin?

I presume you mean the 3D Cartesian Coordinate Rotation VIs. The NI documentation has a decent description of what they do: https://zone.ni.com/reference/en-XX/help/371361R-01/gmath/3d_cartesian_coordinate_rotation_euler/

These are polymorphic VIs. By default, they take an array of coordinates. If you just want to rotate a single point, select the "Scalar" version of the VI (Put the subVI on your block diagram, then Right-click > Visible Items > Polymorphic VI Selector)

3 hours ago, Gan Uesli Starling said:

a 3X3 ARRAY for it's command. I do not grok this concept at all. What's going on?....

And the whole 3x3 matrix makes no sense to me.

The 3x3 matrix is the transformation matrix, which is a concept described in linear algebra. There are different types of transformations: Translation, rotation, shearing, scaling, etc.

In a nutshell: Think of your 3D point-coordinates as a 3x1 matrix (also called a column vector). If you multiply a column vector by a 3x3 matrix, you will get a new column vector. That new vector will contain your "transformed" point-coordinates.

7 hours ago, MikeLV said:

This is by reading the file in Unicode, then convert it to ASCII with the tool vi....

Is the problem coming from the Windows environment language? That means I have to setup a VM in Russian etc to test my code?

Unicode has the ability to store text from multiple languages at the same time. For example, a Unicode file (or Unicode string) can contain French, Russian, Arabic, and Chinese texts simultaneously.

However, when you "convert to ASCII"*, you lose that ability. The converter can only output text that matches your Windows locale. So, if your computer is set to a French locale, you cannot convert Russian text. You need a Russian VM to successfully convert Russian text.

(*ASCII is not the correct name here, but I digress)

Anyway, what version of LabVIEW are you using? If you have LabVIEW 2017 or newer, then your license also gives you access to LabVIEW NXG. NXG has proper, built-in support for Unicode so you don't need to force, interpret, or convert anything.

8 hours ago, PiDi said:

LabVIEW forgot how to write text on the screen

Does a reboot fix things?

If not, try clearing your font cache: https://winaero.com/blog/rebuild-font-cache-windows-10/

5 hours ago, Neil Pate said:

For some reason my RT VM is not cooperating and I cannot copy any files across to test.

As a workaround, you can transfer files into a USB stick from your host, and then attach the stick to your VM.

On 8/8/2020 at 8:24 AM, ShaunR said:

SQLite does not support concurrent writes.

Ah, you're right. Thanks for correcting me.

That explains the why @Xin Li found that "some queries are not executed": If 2 web service VIs try to execute a write query at the same time, one of them will fail.with an SQLITE_BUSY error and the data is lost.

On 8/5/2020 at 3:59 AM, Xin Li said:

Because I want to handle simultaneous web calls, I am making the web service vi reentrant. Not sure how to log all the queries when it is reentrant. Could you give me a hint how?

Write extra code inside your web service VIs. The code should take all the query details (query type and parameters) and take all the SQL VI outputs (results, error clusters) and log them to a text file on disk.

However, multiple VIs won't be able to open the log file simultaneously, so you should create a dedicated "consumer loop" in your application. Your web service VIs can pass the log data to the consumer loop via a queue.

On 8/5/2020 at 4:22 AM, Xin Li said:

it will be nice if I can forward all web service calls to SQLite and use SQlite to handle concurrency and queuing automatically.

Although text files don't support concurrent writes, SQLite does. However, it is not bulletproof and it's possible for it to fail: https://www.sqlite.org/lockingv3.html That's why we recommend that you add logging code so that you can see what's going on.

[EDIT: SQLite does not support concurrent writes]

On 8/5/2020 at 6:32 AM, Xin Li said:

When my web service is not reentrant, I can see error produced from "EXEC SQL" call. However, when web service vi is reentrant, I don't see error.

How do you "see" the error? You can't easily use Probes in reentrant VIs. That's why a log file is recommended.

Let your application log all queries to a file. Be sure to log the execution results and errors too. Are any queries missing? Do you see any errors?

No problem.

9 hours ago, Thang Nguyen said:

In some lab they use LIMS to manage the workflow.

It's not clear to me: Does your lab already use a LIMS? Or does your supervisor want to introduce a new LIMS?

9 hours ago, Thang Nguyen said:

I still not sure how should I integrate my test data into LIMS.

The LIMS documentation will tell how how to integrate your test data into the LIMS. Read it to find out.

3 hours ago, Thang Nguyen said:

I was asked by my supervisor about LIMS compatibility of our software.

1. Can you explain in more detail what you mean by "LIMS compatibility"? Which part(s) of a LIMS should the software talk to?
2. What does your software do?

3 hours ago, Thang Nguyen said:

still cannot get much information about technical side of LIMS. somehow I only know that it uses the OPC protocol but beside that I don't have any more information. Could you please share with me some information about LIMS and how do we communicate with LIMS from LabVIEW side.

Ask your supervisor for the LIMS technical manual or user manual. That should give you the technical details of the brand of LIMS that they're using.

This webpage describes a LIMS in general: https://thirdwaveanalytics.com/blog/what-does-a-lims-do/

3 hours ago, hooovahh said:

That's a mighty fine VM you got yourself there.  Almost like having a VM of this Linux RT target is a super useful tool, that helps troubleshoot and debug features of the embedded UI that are at times "inconsistent" as you put it.  For anyone else that finds this useful you should go vote on the idea, and/or contribute to the conversation.

Voted ages ago.

Thanks for posting detailed instructions, @hooovahh: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/NI-Linux-Real-Time-PXI-x86-VM/m-p/3561064/highlight/true?profile.language=en#M2107 That's what helped me get started in the first place!

8 hours ago, D. Ackermann said:

I never looked into VI scripting. Maybe this could be a way to replace all lvlib VIs in a complete project?

Yes, that can do the job. It will take some time to write the script, however. (I'd set aside a few days if you've never done VI scripting before)

Could you simply modify LibA instead of replacing it with a different library with the same interface?

Unfortunately, there is no straightforward way to do this in LabVIEW.

I can think of one trick which takes advantage of the LabVIEW Project Explorer: When a library gets renamed or moved, the Project Explorer automatically updates the links in all of the project's VIs. So,

1. Close LabVIEW.
2. Temporarily delete or move LibB away to a completely different folder where it  can't be found by LabVIEW.
3. Open your project's .lvproj file.
4. Use the LabVIEW Project Explorer to rename LibA.lvlib to LibB.lvlib, saving it in the folder where the real LibB used to be. This will update all your project VIs' links.
5. Click "Save All" on your project to make the update permanent.
6. Close your project.
7. Delete the fake LibB and all the old LibA VIs. Restore the real LibB.
8. Open your project. It should now pick up LibB instead of LibA. (It might complain that the LibB VIs were not in the expected folder. If it does, just "Save All" again and it will be happy after that)

Make sure you back up everything before attempting this; rinse and repeat will all your projects.

Caveat: If your project uses LibA in more than 1 Application Instance, LabVIEW will lock the library when you open your project, which blocks you from doing step #4.

9 hours ago, Neil Pate said:

Note: I do not actually have a display plugged into the cRIO, I was expecting the windows to open on my dev PC. Is this the mistake I am making?

Are those front panels part of your intended Embedded UI, or only for debugging?

When I run VIs on the cRIO "from source", both (1) and (2) work correctly for me on the cRIO's screen but not on the PC's screen (including preallocated re-entrant VIs). Tested with LV 2017 SP1 + cRIO-903x image in a VM.

It is always worth having the cRIO screen visible during embedded UI development because what you see on the PC is not what you get on the cRIO: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LZ9SAM

I suggest spending most of your energy on choosing a VCS for your team, as this is the part that takes the most effort for your team to adopt. I'd say that the other aspects (project management/issue tracking, documentation) have a lower barrier to entry.

18 hours ago, JB_1592 said:

I do think I would prefer the idea of a centralized VCS for our situation.

Can you elaborate on which parts of the centralized model are most important to you?

18 hours ago, JB_1592 said:

Maybe my Google-fu is off, but I'm not turning up a ton of modern guidance on a full tool chain.

I'm guessing it's because a distributed VCS (DVCS) can do just about everything that a centralized VCS can, but the converse is not true (hence my previous question). As a result, the online community (which is far more visible than corporations) are moving to a DVCS.

The 2 reasons I can think of for a company to stick to a centralized VCS instead of switching to a DVCS are:

• Inertia. If the developers are already familiar with an existing tool, there is a cost to switch.
• They want an extremely high level of control and security over the code base. A centralized VCS makes it a bit harder for a rogue employee to make off which the whole commit history (but it doesn't stop them from taking the current snapshot).

18 hours ago, JB_1592 said:

This loses a some of the appeal of a single application

If the separate applications interface with each other well, how important is it to still have a single application/platform?

18 hours ago, JB_1592 said:

I believe our software engineering group is using something along these lines. (Not sure what their CI pipeline is.)

Does your team have any existing interactions with the software engineering group? Can you get any support from them? Do you anticipate your team working with them in the future? If so, then the best choice for your team might be whatever the software engineering group is already using. That provides a lower barrier for collaboration between both groups.

If you expect to be completely isolated from the software engineering group, then I'm guessing there is not much difference between the possible solutions you have listed. All of them will come with an initial learning curve; the important thing is to pick one, get everyone on board, and get familiarized together.

18 hours ago, JB_1592 said:

user management is sort of important. Ideally I'd like to use SSO and enforce dedicated accounts.

I believe all modern hosting platforms support this.

18 hours ago, JB_1592 said:

Maybe a bit of discussion will help solidify the tools and features I'm looking for, and this seemed a good place for it since "works well with LabVIEW" is a factor.

Be aware that none of the common VCSes were designed to work with something like LabVIEW; they were all designed to work with text-based code.

So, regardless of which VCS you choose, LabVIEW devs must learn to take a bit more care to avoid triggering conflicts (and learn to handle the conflicts once they occur).

18 hours ago, JB_1592 said:

CI/CD might be worth exploring?

...

Azure DevOps

How "big" are your team's projects? How often do you produce a new release? Are  there parts of your release process where you go, "Man, this part is tedious and error-prone... It would be great to automate this"?

• CI is most useful when you have a lot of people working on the same code base and/or you have teammates who churn out commits at lightning speed. It can still be beneficial for small teams, but the impact is less pronounced (and the cost-to-benefit ratio is higher)
• CD is most useful when you want to release often, and/or your release process is tedious.
• DevOps is most useful for a large organization who wants better collaboration between their developers and their operators, and who want to make deployment more efficient.

As you described yourself as a "small team with a badly overdue need for SCC", I suspect these are lower priority for you right now. Again, getting SCC in place first will probably be the most helpful; the automations can always be added after you've tamed the chaos.

57 minutes ago, Aristos Queue said:

I think there should be a picture of the current state of the world. You draw a picture of the state you want. Then the tool generates the command line commands that get you from A to B. This serves two purposes: rather than taking an action and then seeing if that did what you want, it puts the UI in charge of figuring out how to get you textually what you're specifying graphically.

Spoken like a true LabVIEW dev 😁

59 minutes ago, Aristos Queue said:

Second, it shows the user what the commands are that it is executing so that you figure out "oh, that's how that is done" so that when the UI inevitably hits its limits (for whatever reason, GIT seems to exceed the complexity of all UIs used to render it), then the user is already are familiar with the commandline interface. 

That's a really good idea

2 hours ago, Dirk J. said:

PCIe-5410

Google isn't revealing anything for me.

Who is the manufacturer of this card? (Normally, the NI website hosts documentation of NI products -- even deprecated ones)

8 hours ago, drjdpowell said:

I have yet to find anything in Git over Hg that is actually useful.

That is expected.

As I wrote previously, Git and Hg are very similar to each other in scope/functionality (but not in workflow details!). 5 years ago, people were saying that we should just pick one or the other and stick with it; we gained nothing from using both.

Today, there is a benefit to learning Git: It gives us easier access to the plethora of code bases around the world, and it helps us move forward from incidents like Bitbucket's bombshell.

8 hours ago, drjdpowell said:

if you want to go to an earlier commit, you just go to that commit.  If you want to make changes, then you make a new branch coming off at that point.  If you like those changes, you might merge that offshoot branch with the main one.

You have just described Git (and SVN, according to @shoneill). The exact steps differ but the concepts are the same.

8 hours ago, drjdpowell said:

I consider the possibility of losing committed work because I didn't realize I was in an "anonymous/unnamed branch" to be a strong negative.

Agreed.

My analogy with an unsaved VI was a poor one, I realized. Unlike a power cut which is quite plausible, it is actually quite difficult to accidentally lose commits unless we ignore prompts/hints/warnings like the ones @LogMAN posted.

8 hours ago, Neil Pate said:

In every other VCS I have used I can pretty much arbitrarily move around the changesets without fear. All I did was roll back to check out some earlier code and my recent changes just "disappeared" from the client. That is very unexpected behaviour. Sure, I was able to get them back by looking up the commits using the reflog because they were not truly missing, but it is really strange behaviour to me.

Yes, Git could be made safer by automatically preserving "detached" branches and requiring the user to manually discard them, rather than automatically hiding them when the user moves away.

I guess I've never encountered this issue in my 9 years of regular Git use because I habitually create a branch before making any new commits at an old point. This highlights the importance of running UX tests on people who aren't familiar with a product!

I switched from Subversion to Git many years ago and encountered quite a steep learning curve but it was well worth it in the end -- Not having to be connected to the server all the time was a great boon.

I haven't used Mercurial much, but from what I read Hg and Git were supposed to be similar to each other (at least when compared to SVN or Perforce)

1 hour ago, Neil Pate said:

Which client are you using? I found GitHub desktop awful and am now using GitKraken which I really like.

Yes, your choice of client has a huge impact on your experience. I find GitHub Desktop far too limiting; I like the power of SourceTree but I wouldn't recommend it to newcomers of Git -- too much power and too many options can overwhelm.

Having said that, SourceTree supports Mercurial too. Perhaps @drjdpowell can use SourceTree to create and manage a Mercurial project, and then repeat the same steps for a Git project? This might help you to see the parallels between the 2 technologies and learn Git faster.

1 hour ago, Neil Pate said:

• I seem to get into a Detached head state quite often. No idea what I am doing wrong but have sort of figured out how to recover from it.

Every single commit in the Git history can be checked out.

• If you ask git to check out Branch X, your HEAD now points to the latest commit on Branch X.
• If you ask git to check out Commit Y, your HEAD now points to Commit Y and is now considered "detached" (because it is not attached to a specific branch).

To avoid "detached HEAD state", all you have to do is specify a branch when you check out.

1 hour ago, drjdpowell said:

The "detached head" is a good example of the problems with git: confusing terminology for something that has no reason to exist.  Why does it even allow commits not on any branch to exist as a possibility, let alone something that is easy to mistakenly do?

I have a use-case for entering detached HEAD state: Suppose I've made many commits recently and then discover a bug in my code. I want to go back to an earlier snapshot of my code, so I check out a commit that I think is good. Voila, I'm now in detached HEAD state and I can run my old code for debugging.

When my HEAD is detached, I think of it as working on an anonymous/unnamed branch (a bit like how I can edit and run an unsaved VI, but if my PC loses power the VI is gone)

Don't let the terminology discourage you; your journey will be worth it. Happy coding!

I believe DAQmx and XNET have different timing mechanisms.

This thread might contain useful clues: https://forums.ni.com/t5/Automotive-and-Embedded-Networks/XNET-Timestamp-and-Windows-Timestamp-Synchronization/td-p/3367619?profile.language=en

On 6/15/2020 at 5:05 PM, Neil Pate said:

I guess the missing square in the top right corner makes all the difference though, there is no way anyone could get confused.

The different letters mean nobody could confuse it with the TechCrunch logo either:

3 hours ago, LogMAN said:

 

 

Good find. I completely forgot that I posted that! 😅

2 hours ago, Neil Pate said:

Holy guacamole! When did this make it into vanilla LabVIEW? I have been using the OpenG one for so long now...  it is present in 2019 and not in 2015..

I noticed its opposite number is also now in, nice 🙂

Even before this became available, the Hidden Gems palette would expose Split String.vi and Join Strings.vi which come bundled with LabVIEW (vi.lib\AdvancedString\) but which are not shown in the palette out-of-the-box.

I'm not sure why NI created new VIs instead of exposing the Hidden Gems ones. I liked the Hidden versions better as they take less space on the block diagram.

Note also that the out-of-the-box version has fewer features:

• The Hidden Gems version allows you to Ignore Case
• The OpenG version allows you to Ignore Case AND Ignore Duplicate Delimiters