ShaunR

Hi All,

 

I have some old code I need to make some changes to, and am not certain what version of LV it is done in. I so not have those old versions installed on my PC, and don't really want to install the wrong version.

 

The .lvproj has <Project Type="Project" LVVersion="10008000"> in it, does anybody know if this is 8.6 or 8.6.1? My suspicion is that is it 8.6.1

 

Thanks

Neil

LV 2010

2013 = 13008000

2012 = 12008000

2011 = 11008000

2010 = 10008000

2009 =  9008000

If you have VI Server on both sides, you can avoid polling, at least in your code.  I do not know if you consider VI Server waiting for incoming connections as polling.

I will look into web sockets.  For some reason, the links in you message just take me back to this LAVA post.  Weird.

Hmm. The quick reply seems to screw things up.

Here they are again:

Websocket demo

Examples

Unfortunately, that won't fix it. The problem is not having app1 (the server) discover app2 (the client). The problem is our network security blocks all connections from a server to a client. So, it is fine for a client to initiate a connection to a server, but the server can never connect back. Apparently this would lead to an insecure network so it is not allowed. (personally, I think this is more due to insecure IT people, but either way it is out of my control).

So, I am trying to think of a way for the client to open a connection, leave it open without polling on it and allow the server to use that connection to send a message to the client at any time. I would love to still use VI Server because it eliminates the need to worry about flattening data, but if that won't work, what is the next best thing?

Websockets were created to resolve this sort of problem since browsers do not allow incoming connections (websockets create a bi-directional TCPIP connection). Some of what you describe is a little confusing to me since you talk about "discovery" and "polling" but that has little to do with TCPIP since you must know the IP address and labview isn't event driven (so must poll).

You can try it and see if websockets do what you need by running the demo on the server and using your browser to .connect ala these examples. When you have installed the Demo on the server, just navigate to the examples website and change the IP address in the example pages for that of your server.

Thanks for the fix!  I wish I had found this thread earlier.  Can anybody create a new build and check it into bit bucket or is that reserved for people on the team?  Can somebody get the fix into a new build?

 

 

I have seen similar behavior.  I can try to replicate it if anybody is interested. What I found was that if GetTypeInfo is being called by two separate application instances they block each other because it's non-reentrant.  I don't think we are going to find a work around for that.  This might be a unique situation that I found because of the multiple application instances aspect but I figured it was worth mentioning.

The fix has already been pushed to bitbucket. The others will review it then, if it's acceptable, drjdpowell will fold in any other changes and build a VIP package for the CR (only he can update the CR).

Answered in the Support thread.

Added Path case to "Variant To JSON.vi" and updated example.

(See this post)

Variant To JSON.vi

Example JSON Variant Tools.vi

I think the default case would be able to handle paths if Variant to JSON used OpenG Format Variant Into String.  Why was this not done?

Because the intention is (was?) to remove OpenG dependencies completely...

It's not a complete replacement, though, is it? I think this algo can fail with certain numbers so you'd have to fall-back to the printf and incur the overhead of running two in series. Maybe those numbers cropping up are statistically insignificant though.

Looks great.

I get the following error when trying to download the free version (after entering details).

Not Acceptable

An appropriate representation of the requested resource /polls/index.php/survey/index could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Actually i can conclude that its better to use TDMS right. 

Wrong. Your specification actually states:

A full featured database system is implemented

TDMS is not a "fully featured" database system.

My supervisor told me not to use the SQL server. Make somthing easy concerning labview itself.

None of this is "easy" in LabVIEW.

1. LabVIEW doesn't support QR codes. There are some threads on this forum for some 3rd party solutions

2. You will not find an "off the shelf" solution as this is a specific requirement that many would outsource - you will have to write it..

3. If you have the Database Connectivity Toolkit - use that (you probably do as you are a student).

4. If you don't have the Database Connectivity Toolkit - use SQLite.

5. You will have to learn SQL.

Check the VI Server: TCP/IP Access permissions.

Yes, there's that. I don't suppose you have a rope to toss down to us trudging through the deep end?

I think the only person that could help is probably AQ.

It's been known for some time that LVOOP takes a long time to compile (I have commented before to those that think hours to compile is acceptable). However. I actively avoid LVOOP so my experience is limited for applications. Some might say I have softened a little since I do on occasion use it for trivial APIs to save connectors. The kind of advice I would proffer would involve converting to classical LabVIEW. I expect that isn't an option for you, though, if your whole architecture is OO..

There was some discussion a while back about mutation history getting very large and bogging down load times. Daklu was moaning about it; I believe. You might try and find it on this forum (I couldn't after a cursory look) and try experimenting with deleting the mutation history (see the conclusion and make sure you have backed everything up) for a class or two and see if things improve. But that's just a wild stab in the dark.

It seems like many people are interested in packed libraries for clean, professional-seeming deployments. While that's all well and good, I'm more interested in if it can do anything to mitigate our pain as developers.

They have identical issues to removing diagrams from VIs. i.e. not cross platform or cross CPU arch.For most developers that create tool-kits, utilities or reusable components that are distributed to other devs; they are not a good choice. If you only have one product and only ever use one OS of a single bitness and that will always be the case then that's fine. - welcome to Labviews version of DLL hell

I personally avoid them like the plague-little upside, huge downside. A LLB is superior IMO.

However. In your case. I can't help but feel the only reason you are considering them is through desperation - to cure the symptom of a much deeper problem.

Can u send me the labview code by dng it? Pl

You already have the code-it is shipped with LabVIEW

Thanks for the replies, I am not sure now if I will be able to get any real use out of it for my application, however I will download the trial as you suggested James and see how it goes.

I've never used "Data Finder" but I just load csv files into a SQLite DB. The SQLite API for LabVIEW has a VI to do this for you, but you can do it yourself and once in there, it just boils down to how you want to view the info using queries.

I want the histogram plot to be in the form of the bell shaped curve..tried many things.. but the plot isnt similar.. need ur help

Yes. See the "Noise Statistics.vi" or "Probability Density Function Estimation.vi" in the LabVIEW example Finder.

Search the labview examples for "Histogram"

Project Probe is not only "NOT on the LabVIEW Tools Network", it's not on LAVA or ni.com either.  From the OP: "I'm looking for great free or paid tools [...]"  Tease.

If there is some tool or product you or your company is working on

Just a bit slow, that's all 

Crypto-G

Project Probe

Windows API

So, i currently have a reusable connection process and you can easily plug in override VIs for open/close/read/write and basically use any connection type you want (UDP, TCP, VISA etc). As it stands now, our process handles multiple connections but if a message is sent out it is sent to all client connections. We are going to be adding some functionality for request-response which will require an outgoing response message to a specific client connection that made the request. I am not sure how to handle the managing of which connection sent the message and needs the response. One idea I had was give each connection an ID, when a request is received, pass the request with the ID to the loop which processes the data, then sends the result back with the ID so the connection process knows where to send it. I could also use the refnum but I don't like the idea of other processes having access to the connection references, even if it's protected by being wrapped in a class, because I have to add in error handling for lost connections outside of the process which already has the code to manage them. 

 

So, I'm curious how people have handled this and if my approach seems reasonable. 

Sounds to me like Dispatcher.

I'm attempting to set up a build server architecture such that I can execute my builds in parallel in remote application instances of LabVIEW. Initial tests are successful insomuch as the builds complete on the servers but there's an issue of the server becoming unresponsive (error 1130) during the build, preventing my client application from gathering results.

 

My initial hack is to set the ping delay on the connection to greater than the expected build time. This seems to work-- I haven't seen a timeout yet-- but is hardly elegant. Should something go wrong I now need to wait an hour for things to timeout.

 

Is there a way to get LabVIEW to prioritize its TCP stack a little more? I really don't like the idea of blindly assuming things are working just fine for an hour at a time, especially if a real network is involved.

 

I'm not sure if there's anything to be done code-wise: if the build is taking up so many resources that the main server loop isn't servicing ping requests I have a hard time believing anything I do in LabVIEW would be reliable because I imagine the scheduler won't exactly be doing so well either...

You could create a VI to service requests and set the VI priority that services your TCPIP to "real-time" to see if that helps. I'm skeptical that it does much re: the OS, but it  may be effective within the labview environment.

I am thinking of expanding on this for a CLA Summit presentation. But before I invest a lot of time, I am wondering how many others think a tool like this would be useful. If you are interested, please reply or 'like' this post so I have an idea of the level of interest in this subject.

thanks,

-John

From my point of view. It's no better and a little bit worse than the hierarchy window since it hides "depth". What I would really like to see is a 3D version of the hierarchy a bit like the  firefox "layers" (we could zoom in and out then,too )

To clarify -- it's an improper mental model to consider the User Event publisher a "queue". When a User Event object is created, there is no underlying queue of messages that grows with the "Generate User Event" method, and so there exists nothing to "re-transmit" to the handler queues. A better mental model is to consider the Generate User Event method as a

<snip>

Heartily concur. This can be generalized to say, lots of different APIs in LabVIEW would benefit from providing asynchronous output streams that adhere to these Events pub/sub semantics. Again, this is in the spirit of enabling concurrent systems development in LabVIEW, which converges to Actor design and the current topic of asynchronous dataflow on Expressionflow.

Actually. Looking closer. My initial "thought" was wrong. Event registrations aren't equivalent to "Dequeue" (i.e. destroy the element) since you get multiple elements in multiple Event Structures. So if your "semantic awesomeness" is advocating they do behave as I described. Then we are in agreement.

Your in danger here of becoming an architecture astronought.

Your typical architecture astronaut will take a fact like "Napster is a peer-to-peer service for downloading music" and ignore everything but the architecture, thinking it's interesting because it's peer to peer, completely missing the point that it's interesting because you can type the name of a song and listen to it right away.

 
So. Breaking it down.   
 

Not explicitly true -- for Queues, an enqueuer and a dequeuer are both accessing the same Queue object, whereas with Events, the enqueuer and dequeuer are interfacing with two separate objects -- the event publisher and the event registration/subscription.

 
OK. Lets changed make a little change here.
-- the event enqueuer and the event dequeuer of that Event Registrations queue. Lets not get confused by extra abstraction layers.

So you are 1/2 right. Queues do access a single object. But so do events which have access to their own queue which just happens to get populated indirectly rather than directly by the enqueuer.
 

Any number of writers may write to a Queue, and you may have any number of readers as well; stated another way, contrary to popular belief, you may have multiple asynchronous dequeuers pulling out of the same queue.

 
Not really. You can only have one dequeue as dequeue destroys the element (readers and dequeue confusion here) and sure you can "peek" the queue, but that does not destroy the element. So having "multiple dequeuers pulling out of the same queue" is unpredictable and results in unwanted behaviour on the most part. In fact. It is a common bug by rookies. This is encapsulated by the axiom that queues are "many-to-one" and if you keep to that, you will be fine..
 

Events have a bit different semantic than Queues in LabVIEW -- there must be one and only one Handler bound to an Event Registration at any one time,

 
Why is that? Is it because the Event Registration primitive is, in fact, the symantics for a unique queue? If you do add multiple handlers, do you not end up with the problem I described previously about multiple dequeuers? I would say they have exactly the same semantics as Queues.(just different primitives) and you can only have one outbound (aka dequeue) at any one time. The difference arises from the way the Registration Queue is populated.

yet there may be (0,N) Registrations per publisher. With this extra level of indirection, I don't know if we can even properly classify Events as being something-to-something, but rather (N publishers)-to-(M registrations)-to-(0 or 1 handlers bound to a registration at a time).

 
Of course we can. Come back down to the troposphere for a second.   

A fairly good approximation for Events in LabVIEW are a queue (lets call it "event queue") to a number of queues (lets call them the "handler_queues") where "event_queue" re-transmits the enqueued element to the other queues before being destroyed. In this approximation, we need a VI that adds a queue reference to the "event queue" and registers a unique ID for a "handler_queue" so that when an element is enqueued to the "event_queue" it copies the element onto each registered handler_queue (iterates through all handler_queue0-N). Each handler_queue (just the usual while loop, dequeue element and a case structure), is waiting and dequeues from its respective queue. So we can create event-like behaviour using queues, but have to do a lot more programming to realise it.
 
So we have one (event_queue) - to - many (handler_queues). This is essentially the Event system in LabVIEW.

We do exactly this all the time with TCPIP servers where events would be a much better solution but, sadly, lacking.
 

 
Breaking it down:
 
Queues are many-to-many, one-to-many, one-to-one, or many-to-one, depending on what makes sense for your application domain.

I will counter argue that if you are trying to use queues for anything other than many-to-one (one-to-one being one of the intersection edge cases I mentioned in my previous post); use something else. I have already outlined how you can use queues for event-like behaviour. But whats the point when it is handled by the language for you in Events? Just because you can, doesn't mean you should - the right tool for the job.

Many-to-many: Only practically relisable with architecture.
One-to-many: Events. Notifiers.
One-to-one: Anything you like, (Queues, Events, Notifiers, FP terminals, Globals et. al).
Many-to-one: Queues.
 
 

 Events support the same configurations, though with one additional level of indirection (which enables a host of additional design patterns), and the caveat that there may never be multiple readers (Event Handler Structures) simultaneously bound to one Event Registration. This caveat is the one I would like to see lifted, that Events might act more like Queues, in order to better support concurrent processing.

As I have said already. They behave exactly like queues which is why you cannot have multiple dequeuers (Event Handler Structures) attached to the same registration just as you cannot have multiple dequeuers for a queue without unpredictable and unwanted results.

I think the issue here is confusion between reading (aka peek) and dequeueing which has been lost as you've gone further up the abstraction thought process. The destruction of the element is a key attribute of queues and once omitted you need other mechanisms to either filter or remove elements.The difference between the events and queues isn't how they are consumed (events uses queues too). It is how they are populated and this gives rise to the ability to create "one-to-many" (events) from multiple  "many-to-one" (queues),all wrapped up in a nice, neat package.

What advantages would you expect events to have over queues though?

Whilst there is an intersection of edge cases They are not synonymous.

Queues are many-to-one. Events are one-to-many.