smithd

Not really, an issue is still an issue, even if it isn't actionable. If there is one thing I learned, there is absolutely zero way for me to predict what CARs get fixed and what CARs get shoved on the backburner and ignored for a decade. In this case we're talking about an OS level deadlock, outside of any application code on a software and hardware platform sold directly by national instruments.Regardless of if its reproducible or not, its still an issue to be reported, and there is no reasonable way for it to be my problem just because I'm the only person who hit on the specific combination of magical conditions to cause it. NI literally sells us this stuff on the basis that things like this just dont happen. PSEs are part of R&D, so I consider talking to them an escalation. AEs have to be willing to accept that they don't know something and actually ask the PSEs for help.

I pretty much only make service requests when there is a problem that an AE can't solve, so I think I have a different experience than you For example, did you know that labview RT for pharlap can deadlock at the OS level? Neither did I (well I mean in theory sure, but I'd never seen such a thing). There was no CAR for it, and there is still no CAR, because the AE wouldn't escalate unless they could reproduce it. Through trial and error I'm fairly certain its related to some combination of hyperthreading and IEEE 1588, but its impossible to know for sure because it isn't reliably reproducible, and theres nothing clear in logs or memory dumps or anything like that. Either way, my answer is 6 in the last year, of which: 1 was resolved quickly and painlessly 1 ended up being another vendor's issue 4 didn't particularly resolve my issue

draw.io has a set of process control glyphs which you could pull out, but they are just shapes, no colors or animations. I think its supposed to be used for P&ID diagrams.

apache and MIT have similar benefits, I wouldn't count them out. But yeah, I'm glad I don't have a commercial product to worry about. Has anyone ever looked at the ni-provided legal info in the program files/ni/shared directory? It makes me sad how much effort has to have gone into that.

I am not a lawyer and neither is anyone you are likely to get to respond here. If your company has a legal team, I'm pretty sure they would prefer you ask them rather than the internet. With that said... On the first statement, this sounds very clearly insane. More importantly, I would assume that if it *were* correct, you posting the question here would provide a record showing that you and your company violated the license and so posting here (if the entire idea wasn't crazy) would open you up to lawsuits. On the second (VIPM package which is GPL), as I understand it this means you must make your code open source. Take a look at https://choosealicense.com/ for the alternatives. An important distinction is between the GPL and LGPL.

I would interpret that the opposite way...the point of a serialization format like json isn't to go string->data->string and have the strings match, its to go data->string->data and have the data match. According to that line in the wiki, that would seem to require 17 digits. 15 digits only handles the s->d->s use case.

or smart cameras: http://www.ni.com/en-us/shop/select/smart-camera

I used to be in favor of this, but I've found that user events are too buggy to use effectively in this manner without being sad.

https://forums.ni.com/t5/LabVIEW/How-to-link-SQL-server-to-Labview-with-Database-Toolkit/td-p/967330 Fundamentally you need to pick out a driver that supports remote communication (readme has specific info on ms sql), then you make a configuration file or string which describes how you will talk to it (see link above), and then you use that to initiate a connection as shown in the examples in the example finder.

I dont know how much of a use case there is for this toolkit on RT, but I absolutely would branch it and make my own copy if you asked me to use a pre-build VI to script a different path into an RT exe in order to safe a few usec per call

I would guess in parallel you incur locking overhead either inside labview or the kernel. The problem with a constant set on install is it would be problematic for rt. I would suggest a subroutine priority fgv with caching. Would that not be the best of both worlds (except path-in-node)?

For moving to 2017, was it just VIMs on the palette? Or did you encounter actual bugs with vims in 2015? (I ask because I have my own internal branch of yours, and I just put the vims in as drop VIs). Edit: It looks like my approach did not work -- the vim's don't auto-update. Maybe before they polished it in 2017, vims couldn't adapt if their type was variant? I know that polymorphs have trouble with variants so maybe its similar. I also removed the private marker for variant to json text. Its still useful on its own, and making it private broke backwards compatibility with my code. Realistically this probably only effects me, but it is vexing when people make useful things private (for example my bitbucket request for a public version of the "json type.vi" function) With the numeric formatting, what was the reasoning behind using 15 digits (%#_15g) vs say, 20? Edit: I saw this on the wiki-- "This gives from 15 to 17 significant decimal digits precision. If a decimal string with at most 15 significant digits is converted to IEEE 754 double-precision representation, and then converted back to a decimal string with the same number of digits, the final result should match the original string. If an IEEE 754 double-precision number is converted to a decimal string with at least 17 significant digits, and then converted back to double-precision representation, the final result must match the original number."

what about a calculated path (eg build a path control -- set to empty -- with your lib path). I was surprised by the 600 usec benchmark above -- my recollection from a few years ago was that overhead of a constant name in the CLFN vs one on the diagram was only a small overhead, maybe 13 usec vs 15 usec for some stupidly simple dll call.

In contrast, today I right clicked on a random VI* in my project and labview hung...through several restarts, until I just gave up sorry, were we being positive in this thread? *to be fair I needed to use lvoop for something, so random crashes and hangs are expected

I need rt, I need fpga. Most of my systems have less than 2 GB of ram, the vast majority are at 256 or 512. Database access is valuable as well, although we now have alternatives for mysql, postgres, and sqlite. I only really need 64-bit for database access tasks.

Erm...no.

awesome, thanks for sharing!

This makes sense on the surface but I don't understand the real impetus for the change -- you kind of jumped from "its big and complex" to "here are solutions I came up with for the problem". Do you need to be able to reuse your core state machine inside of another application, or share behavior between implementations? Most of your solutions sound like they are still tightly coupled to a specific UI (eg get set control values), you're just adding an additional layer of code. More in reply to the other posts, since as I said I dont totally understand the problem you're trying to solve: the way I do most UIs is to have a single loop with the following features: Event loop async call references for any long running tasks w/dynamic event for result this is something drjd mentioned using in his messenger library as well I had made something which somewhat generalized it, which is where I had the conversation with drjd state cluster (or class)+functions which operate on it (the 'model' for lack of a better term) state cluster for any ui-specific data local, "redraw" user event which uses one or both state clusters to (in most cases) refresh the UI from scratch So my "decoupling" occurs in only one place -- my state cluster and the functions which act on it are separate from anything specific to a given user interface.

Your link just makes it sound like qpid is buggy If its windows, seems like you can just use their .net code: https://qpid.apache.org/releases/qpid-cpp-1.36.0/messaging-api/book/ch01s03.html

well that one i cant answer...at this point probably the tech preview for nxg :/ Its actually kind of interesting nobody has taken diff on as a vi scripting exercise. merge makes sense -- it seems hard -- but diff seems relatively easy if you consider that the built-in diff doesn't do a ton of semantic filtering on changes.

Glad that worked. And yeah, the sourcetree/git was only because its available even from a single machine without setting up a server. The other differences between git and svn aren't sufficient to get worked up over.

Diff is professional only, not full: http://www.ni.com/en-us/shop/labview/buy-labview.html ("Software engineering tools" section)

Ah yes I see you now on the other page. Either way, sounds like maybe time for a repair. Or is there a possibility you don't have the appropriate labview version activated?

Thats weird...what happens if you run the compare from labview tools menu? Does that work? Also, more generally if you havent seen: https://lavag.org/topic/17934-configuring-git-to-work-with-lvcompare-and-lvmerge/?page=2

Since you wired up the file path directly you're performing an implicit open. I would assume that the implicit open uses "read/write" (the default) rather than "read-only" and "write-only" , and opening the same file as writable twice seems like something which labview or windows would take issue with.. Maintaining the reference rather than the path should fix this, as would manually opening the file with the selected access mode.