ShaunR

I tried suggesting something like this some years back to "keep out the riff-raff"

Wouldn't have kept me out

Most of these I think could be alleviated just by turning on the alignment grid and "snap to".

I can understand that sentiment

But my rule comes from the fact that if I move a VI (by nudging it one pixel up and to the side with the cursor) to see if the wires are correctly attached to the right terminal, and yes that has been and is always one of my first methods when debugging code that appears to behave strangely, I want to see the wires move with it so I know approximately that they indeed are attached to the terminal they appear to. With hidden bends you don't have that at all and need to move the node sometimes many steps to see if they really attach correctly. And shift-cursor is not a good way to do it.

Too many hours on Linux Double-click will highlight the entire wire and show all kinks, even if behind a primitive

 

And to Shaun and others, be happy I'm not in the LabVIEW development team. I would penalize any VI call that is not using the 4*x*x*2 connector pane by an extra 1 ms delay, and document it as a special optimization in the compiler of the 4*x*x*4 connector pane pattern.

Try running the Static Code Analyzer. Any code is crap according to that but it is good for finding wire bends or wires backed up/bent under controls and icons.

Just don't tell my boyfriend about her.

ไม่หึง.ไม่รัก

If you went this route you could replace the hilbert function with this implementation in what I sent you and still capture the transitions in a similar fashion.  Lots of options.

I wouldn't. I'd just take rate of change (dy/dx) of the Vrms and if it went outside a value, count the event (assuming it's a bit noisy and not zero when unchanging).

Use the AC & DC Estimator VI to measure Vrms and just note when Vrms changes.

Came across a nasty little issue today.
 
It seems that the Mouse Events are not backwards compatible between 2009 and subsequent versions.
 
Following is a link to a zip file that contains two VIs. One is saved in LV2009, the other in 2011. If you open the LV2009 version in any later version you get a broken wire. The 2011 version, however is OK when opened in 2012/13. If you back-save (Save For Previous Version) from a later version to 2009, you also get a broken registration reference wire when loading back up in 2009 .  
 
http://www.labview-tools.com/download_file/119/309/

.

As time goes on this "Windows API" becomes less useful and more dated

That's disappointing. I've nearly finished my MDI API

Well. My list doesn't just include stability. It also includes performance (both exe and IDE).

There have been only 2 that have been exemplary (too long ago to remember exactly before 7.0, but started at around 2.x and have no bad impressions). Only labview before 8.x was bullet proof IMHO and even as far back as 2.x it was rare to get an Insane Object (the equivalent of a GPF in the more modern versions) which I experienced 2 or 3 times a year..

So. Outstanding editions:

7.x

2009

There have been some real dogs too

8.x (yes all of them!)

2010

That leaves high project risk but maybe worth it for the features or if specific fixes address business critical problems you have experienced (they didn't for me)..

2011 ("Performance and stability release" was a joke, and I said so at the time)

2012

So on to 2013.

My experience so far is that it is excellent and, if it didn't have the JSON issue or it had a a few more new events, I would have upgraded from 2009 when SP1 comes out. The issue for me is that when installing  the latest DAQ it states that it will bork 2009 DAQ functions and I'm not prepared to do that. So whilst I might have upgraded to LV2013, I am now and will be forever stuck at the current version of DAQ until I abandon 2009..

Well, on that note I have all versions of LabVIEW installed on my system since about 5.0. A few months back LabVIEW 8.2.1 started to crash on startup but I didn't have any urgent need for that to work so left it at that. I did regularly check if it still crashed to because there was a potential project that might need a minor maintenance work in the near feature.

 

Just before installing LabVIEW 2012 I tested again and it still crashed. After installing LabVIEW 2012 SP1 and the according device driver DVD I tried again and it now worked. And no, I prevented the DADmx driver from removing any support from the LabVIEW 8.2 directory by hiding it (and the other versions, the DAQmx intaller wants to rob of all DAQmx VIs) during the install! So while 2012 may be more stable, the underlaying device drivers can make a much bigger difference.

Have you tried updating from the 2013 device driver DVD? A nasty little gotcha!

I definetly agree with you in this. Initially, I was planning on having the "Upload VI" as nothing more than a very simple VI that does nothing more than reading the updates, logs etc. But as the project went on and new functionality that I wanted to add to the main VI, then the Main VI became too congested and I started making the Upload VI more complicated until it became what you see now.

 

Having separate modules for this, and having a communication link for data and messages for these modules would certainly be the way forward, but unfortunately, I'm used to statemachine type of structures and not much in module based work.

I started thinking on how to handle different errors, i.e. have each module sort its own errors out or delegate them to a central error handling module, where error logging then comes into play.  While all that is going on than I remembered various race issues that can creep up (specially if I continue using my current framework), and somewhere around here my head started hurting   . 

 

So I thought coming here and get some help along the way  . 

You can still keep your state machines. Just contain them in modules with defined responsibilities and interfaces so that they are encapsulated..

I started calling myself LabVIEW Overlord as a joke, because people throw around the term Guru all the time.  Only now it sound pretensions when someone introduces me as the LabVIEW Overlord.  Also someone may take that as me pretending I'm better then a NI Knight, which wasn't the intent either.

That's why I like my title of "Archetype". Old and experienced; one of the original blueprints familiar with the arcane arts of LabVIEW

I completely agree. Don't get me wrong, I love QD, but I don't care for the collection of arcane keystrokes that are used to bend it to one's will. Ideally what I'd like is not so much to have a floating window open at all times, but a tool like yours come up due to some context like quick-drop does.

I don't use quickdrop but I've always wanted a palette that shows (say 10 of) the "most used" VIs similar to how chrome shows the most visited web pages. I've also wanted dockable palettes so that the "favourites" could be docked to the top of the screen. I think it's very limited use of the screen space to have the floating windows (urrgghhh. The probe window!). The same could be applied to "quickdrop". Just dock it to the top of the screen and have a single text entry like the chrome address bar that drops down when you type stuff into it and goes away when it loses focus.

If you're talking about the knob eyeballs, someone did ask about it later on the NI forums and proper answers were posted, although, like I said, I think that under the constraints of a speed coding challenge, the actual submissions were close enough to the rules to be acceptable. Here are a couple of the ones which are worth opening. Mine got Darren to endorse it as "creepy". You can't do much better:

 

http://forums.ni.com/t5/LabVIEW/Knob-Eyeballs/m-p/2523334#M766596

http://forums.ni.com/t5/LabVIEW/Knob-Eyeballs/m-p/2522728#M766458

Well. It wasn't particularly hard or time-consuming to code a proper solution. The caveat however is that you either  needed to have done it before and already know the equation (there are lots of these kinds of things in Javascript- including this one) or you needed to very quickly realise the trig and the primitives to use  (usually from experience). Just the x axis doesn't cut it for me.

That's why I think it is a fantastic task. Easy and quick solution if you know it

(Yeah. Yours is super creepy. A fascinating window into your psyche )

Correct, currently the Main VI does this through the "Check Availabiltiy" state. However, I'm worried the way that I am doing this may be abit of an overkill. i.e. I'm thinking that there should be a much easier way of doing the same operation that would result is less confusion. Usually, the simplest method is the best method, and I'm worried I haven't approached it that way. 0

So far, the main VI keeps track of all the jobs (i.e. Uploads and Downloads) through their properties of queues where they were initially generated from. Their state such as Pause, Cancel, Exit, Ready, etc. is kept track by the main VI and when the right conditions are met, the token is then given by the main VI to the right job. When that Job is paused, the Main VI then goes through the list again and checks the next Job that meets the right criteria, and so on. 

 

Indeed. I suspect that a separate "Job Manager" would simplify things immensely which is why we are talking about modularisation.

Well, the Upload VI, has 3 such loops. The Progress loop, the Log loop and Pre-processing loop. The progress loop updates the progress of the Upload VI (i.e. the progress bar, speed etc.) where the same values are then also sent back to the main Update loop of the Main VI. The same happens with the Log loop, where the log indicator of the Upload VI is Updated and the same log is also sent back to the Main Log on the Main VI. I kept this loops seperate because depending on the amount of Logs generated or the Updates, I didn't wand to occupy the Main loop that deals with Uploading articles itself. 

Again. If you have a "Log" module, then it can do its thing whilst the UI gets on with just updating the UI. On the surface, the UI seems to be trying to do too much (it's an aesthetically pleasing one however - much better than I could mange) I am still maintaining that delegating much of the current UI functionality into separate modules will be beneficial in terms of maintenance, readability and robustness. I'll see what I can come up with.

I will also try and buy a block account from newsreaders so you can also run the program and see how it works. I will post the information as soon as I'm finished. 

 

In the mean time, tweaknews https://www.tweaknews.eu/?page=order&product=1   seem to be providing free accounts for 10 days, but since I've used it in the past I can't create another account with them. 

That'd be great. It's an interesting project and I'm keen to play so if you can get that done, so much the better (PM me log-in details if necessary). I'll take a detailed look at the code when you've set that up.

What will be the end product of this software? Commercial? Open Source? Lavag? Do you have a deadline?

I wasn't at the challenge but I could tell there was some kind of discussion there about the implementation.  It met the specified requirements did it now?  I realize it may not be the intent but that is because of poor requirements.

 

Now that I think about it I can agree with your front panel specifics, because you mentioned what is considered an object on the front panel from the perspective of LabVIEW. 

I agree - poor task indeed. It was supposed to be a "coding" challenge, not a "semantic interpretation" challenge. Christines was fantastic though and, to my mind, no-one got the solution.

Yes, i have checked all the dlls by using this tool several days ago, and those dlls are reported to be no bad, but some stubs.  And for these 10 dlls(may be more), when i disable any one of them and enable the remaining, then i can deploy my code to RT. 

 

 anyway, many thanks to you~~~

Is it a case that it used to work on the RT platform and doesn't now. Or is it that it works in windows and now you want to use it on the RT platform?

Ayayay, when things happen they all seem to happen at the same time. I get the attached error when trying the built specification. I think this may have to do with clashes between various VIPM packages that I've installed. I have to go though them and sort this out later. 

 

As for the files itself, I'm now providing the full folder in my current LabView version i.e. 2012. 

 

As usual the link is below since the attachment is bigger than the forum allows. 

 

https://mega.co.nz/#!oA8SnRrJ!Uop2vwECVGQk_pCsovLhFnb9kCwtEwc0VMvD6ZVVm8E

 

 

As for what you've just mentioned Shaun, you are correct. The main VI first initializes the whole set of connections and then provides the exact same ones to all the jobs waiting. However, the main VI organizes and makes sure that only one of the jobs (i.e. either downloading or Uploading) can use the connection at a time. The reason I provide them all with the same connection is that when a job or process is paused, the next job in the main queue waiting starts to work straight away, since the previous job is now paused and no longer using these connections, the next job can now start using them until finished or the user pauses that job as well, and so on. 

 

 

 

Kas

Everything seems to be there. Sweet. I'll take a more detailed look later. QSMs are notoriously difficult to follow without state diagrams and there are a few in there (Did I mention how much I hate the JKI statemachine )

So. If the main VI organises and "makes sure that only one of the jobs (i.e. either downloading or Uploading) can use the connection at a time". This is what I mean about modularisation. The UI just handles the UI stuff only and a separate module has responsibility for managing the connections/jobs.

As a first pass (very quick) glance, you seem to be sending a lot of messages and data to different loops which don't really do much apart from pass them to other loops or VIs (please correct me if I'm wrong). This is a code smell to me that you may be better off with events rather than queues as different parts of the program can register for the same messages and have their own message filters if necessary. This approach also allows better modularity as you can create self contained message handlers that deal with very specific usage aspects of the message data. A good example of this would be the status where you want different parts of the program to obtain info about the individual downloads from the connection manager and update log files, and the UI . So the sender broadcasts it's data for anyone interested to hear, rather than pushing the data to a number of specific queues.

4*2*2*4 should be the standard and strictly enforced for all LabVIEW programmers, if I had a say in this!

Yeah. Well. You'd run into problems with me then, because I use 4*1*1*4 almost exclusively. With this layout the programmer has the choice to place key parameters or indicators (like AE typedefs or event refnums) above or below the VI depending where there is more space and/or less wire crossing. With the introduction of polymorphic VIs; there are only rare occasions where more than 6 inputs or outputs are required..

There are still a load of VI's missing (like the ones that actually upload and download. I would suggest you put all the files in the project (not just the top level one) then make a build specification for "Source Distribution" (don't forget to manually add the dynamically loaded VIs).

However.

You are opening all the TCP connections (the TCP connection pool) in the top level GUI and then passing the refs to both upload and download things that are missing (so I don't know whats in them). Unless the upload and download managers (the things) negotiate between each other, I can guess,that when you set the No to 30 they both think they have those 30 connections

I would let each manager open it's own pool of connections or use a LV2 (not re-entrant) self initialising global that creates them on the first call only and place that in both (i.e not in the top level and not passing them).

Not knowing what is down further, so you may already be doing it or it may not be pragmatic............

Generally with this sort of thing, I would let each download/upload subVI connect, login and download/upload and not open all connections at once, rather, limit how many spawned processes there are with the manager which would ensure that only X are running and queue additional requests until one or more has finished. This suits a messaging architecture, however, since the manager is always running and you just send it the data (as a message or series of messages) that you wish to action (upload or download). This approach completely modularises and separates the UI from the manager and the manager from the downoader/uploader code so they all can be run in isolation as stand-alone modules whilst developing and debugging

I would suggest modularisation.

Create a VI that connects and does everything you want it to do for one connection, then just launch 30 clones (or however many) of them on demand asynchronously. You only need to send status data and the final file data to the main UI.

(Some VIs are missing btw Pars Que States, Add State To Que etc)

Take a look at the quick and dirty example in this post. Download.zip

The purpose of defining the differences between QSM, QMH, and MHL is to try and make them meaningful. 

Here you go.

MH: Message Handler. Executes functions based on messages.

QMH: Buffered MH that operates on an ordered list of messages.

QSM: A flavour of QMH that operates as a state machine.

MHL: a description of a Message Handler (MH) because it manifests itself in LabVIEW as a while loop.(redundant).

hi everyone here!

 

recently i have come to a odd problem with lvrt(ets) and have no idea about how it goes. 

 

My project uses 10 or more dlls which were wrote by third party and had been put into the RT's C:ni-rtstartupdata  folder, and this path had been added to the system find path list. Each of the dlls may have several VI calls(each for different functions in the dll) in the project. And when i try to deploy the whole project, my RT hung with one of it's cpu went to 100% loads.

 

And the odd thing is, when i try to disable one of the dll (means to disable all the vis that call the dll through the "call library function node"), the deploy goes with no error and my application can run as expected except the disabled parts! During the past one week's struggling with this deploy problem, once i can come to a particular configuration (by removing some no use modules in the RT or changing the dll call's  from "run in UI thread" to "run in any thread"), and under this situation ,i can deploy my project to rt, but when i run, a exception string appears on the RT's screen, which says "flushing disk cache" and something like "system error".

 

Here i have two questions:

1,   does the ets os system have a max number of user defined dlls that can exist in memory at the same time?

2,   does anyone come to the "flushing disk cache" error before in the ets system? can you share some experience with me?

 

any suggestions are welcome and will be appreciated.     i am looking forward to your share, many thanks in advance!

Have you checked the DLLs with the RT DLL Checker?

Everyone thinks that the CLAD exam is to test for understanding. It isn't. It is a test for Compulsive Labview Alignment Disorder. So all certified programmers have this pre-occupation.