ShaunR

Unwrap Phase VI

I expect you are. When you program for machines and instruments from the real world. Edge cases of the programming tool are pretty dull

Not quite since you can only build one "Top Level Vi" according to the Application Builder (so it's not a "hint") and "sub VI" has a definite dependency hierarchy (only appears in the hierarchy window if tied by the diagram) - pedantry prevails! 1. All VIs have front panels and diagrams at design time. 2. What does "Top Level" mean? (top level of application? top level of a hierarchy of other VIs? Top level of a notional design partition?) 3. If one VI calls another VI dynamically then exits, is that called VI a sub vi of the caller that has now exited? Currently, the only unambiguous parlance is that if a VI has another VI on it's diagram, then the VI on the diagram is a sub vi of the VIs diagram. I'm suggesting that if you define "Top Level VI" as being the pinnacle of a stack of VIs tied by its diagram, then everything fits nicely and you don't need all the other nomenclature. You just need to rename what the application builder calls the application entry point (which is currently Top Level VI) and that removes all ambiguity and AQ can name his "Not-Top-Level-Vi" as a "Top Level Vi". That IS simple and can be explained with the VI hierarchy window to the confused.

I think you are thinking of the myRIO. The myDAQ is A/D IO only and what they used to call Elvis.

I believe you can create a counter using the DIO on a MyDaq. If you are doing it as a technical exercise - fine. If it is for a real project then I would just get a USB to serial cable and be done with it

SubVI is the term since the "Top Level VI" is descriptive of a pyramidal hierarchy and the expectation is for all other VIs to be SubVIs of this. Historically Top Level VI has been the equivalent of "Main" in other languages and is a monolithic application viewpoint. If we view this as a tree, it seems clearer where you question arises from. Classical labview hierarchy terminology basically defines the hierarchy tree as being: Root = Top Level VI (Singular) Node = Sub VIs. and you are saying "but yes, we also have these other sub VIs that are more cohesive than other sub VIs so lets have" Root = Top Level VI (Singular) Leaf = Non-Top-Level Node = Sub VIs. In this case, I suppose you could call them "Leaf VIs" or "Subordinate" VIs or lemons but it isn't really clear what they are or how they differ from Root and Node. However I don't consider a "Top Level Vi" to really be the top level of the application. Rather, the Top Level of a module, process and/or grouping and I tend to talk in terms of a hierarchy tree where Root = Root VI, Leaf = Top Level VIs (not singular) Node = Sub VIs. Here, the Root is just an entry point so can be a Top Level VI, a dynamic launcher or the IDE and there is no need for a notional distinction between sub VIs and non-top-level VIs since it is already understood that a top level VI is the pinnacle of a hierarchy of sub VIs, but Root VI is the pinnacle of the application. My though process

According to the spec 13 bit is the resolution, not the data format. If you want to get sense out of the raw 13 bit register, I think you will need to calculate it via the following formula if its not already done for you. g = (register_value-4096) * 0.00390625 where the "register_value" is the UINT16 provided by your high and low bytes. That should map the 13 bit register onto the +16 to -16 g range..

It's a gift. Or at least you should look at it like that. I call it the Aura of Technical Doom - an innate ability to break anything technical sometimes just by mere presence. If you are a quality engineer with this special power, you are feared by corner-cutting engineers far and wide. These special people are also the bane of demonstrations and usually illicit the phrase "it was working earlier" from other engineers and sales people

Confirmed. Introduced in LV 2013 and doesn't affect LV 64 bit...

I have seen something eerily similar as it rings a lot of bells, but it was quite a while ago now so it's a bit fuzzy as to the exact symptoms I saw. It was down to a full path of the class in an lvlib instead of a relative one. It may also have had the same in the class itself for a couple of methods; like I said, it is a bit fuzzy Once I manually edited the full path to a relative one, the problem went away. Might be worth seeing if you have something similar. It's easy to spot using a text editor

That's because the first VI is his virus payload delivery VI It might have created a directory somewhere with a load of picture control files in it before disappearing (if you are lucky) or it may have uploaded pictures of your partner to facebook along with escort details . You should always open individual VIs in a project,when you don't know what they are. Then they won't run when opened and you can inspect the diagram.

undocumented = there is none.

We've been asking for years to be able to create native controls (and create them dynamically). We got X-controls instead. Whilst the models define the art, there is no way to define the behavior which is hard coded in the LabVIEW exe. Apart from the models that you have found, there is also the ability to load plug-in controls as DLLs. It is undocumented but one of the well known labview controls uses this method so you may have more luck with that (I'll let you find it ) as at least in theory you should be able to define behaviour.

Fair comment. You asked how to replace an enum. What you got, though, was a suggested architecture framework that will shape your whole application. OOD !== Classes.

Well. I don't know the answer to your question since I only have TS 2010 as well. But I do know that Timestamp is basically UnixTime and has been around since before MySQL version 4 (probably as far back as version 0 ) and is generally considered a legacy format (runs out of steam in 2038 so beware of birthdays ). DateTime is a far superior option to Timestamp (can be used for date calculations directly and runs out in the year 9999) and really should be used if you have a choice. If you really want timestamp you can get it from DateTime by using "SELECT UNIX_TIMESTAMP(the_datetime)". anyway. Saying that though. I am guilty of using Double Precision on occasions since that is a direct conversion to LabVIEWs datetime type but I have not used the Timestamp data type in MySQL for a long time now.

Encapsulation of state, I expect.That is about the only reason I will consider LV classes - stateful drivers/APIs like websockets or HTTP. It's a little bit cleaner than LV2 globals and doesn't multiply like a tribble. People also forget that Hardware Abstraction was solved many years ago by firmware engineers. It's called SCPI and, what dya know? It's strings I was going to write a presentation called "String Theory - The fundamental building blocks of programming" and demonstrate that you can create complex and scalable systems that transcend networks, using a service oriented, string messaging design and bugger all code. No-one seems particularly interested unless it has classes in it though Meanwhile..........back on topic

If it 'aint broke, don't fix it. (Not kool-aid, more like resisting the Tribbles. )

*sigh*

Have you tried using the JSON API? That allows nested clusters of arbitrary types, unlike the native LabVIEW one.

I just created a new empty project. Created some some untitled VIs then closed the project (button top right corner) and it seemed fine. It asked me to save the VIs and then closed all the open VI FPs and diagrams in the project. Are you seeing this behaviour on an existing project that was converted to 2014?

Thats where you start. Modularise. Compartmentalise and simplify. In tLabVIEW. It's usually a bottom up, iterative process and diamonds are a programmers best friend. Oh. And refactoring doesn't necessarily mean re-architecting.

Agreed. It is a language artifact but the escape isn't abstraction it's modularisation. Abstraction just makes the fat pipes fatter. Again agreed. If you break the actors into identifiable groups to form APIs (and thus limit their inter-dependencies), you can then use AF for internal API messaging but strings for inter-API messaging. This also helps you bridge the network gap as you essentially use use AOP for modules and string based SOP for process. I remember a discussion with Daklu where we discussed this with his Lapdog stuff.

Really? I find it all rather depressing. Ethereum? Don't know much about it.