Grampa_of_Oliva_n_Eden

Hi Hans,

I think you are doing something wrong with "writing shared variable with datasocket into the database".

You want to write traces with custom timestamp in citadel, so use the "write trace.vi", you have an input called timestamp. Create libraries with upmost 1000 variables (the SVE is at its best with libraries with less than 1000 sv declared) and use the binding in variable declaration. Log with events structures.

Actually I have an application with more than 5000 variables, with logging with custom timestamps, and update rates below 500ms and works ok.

cosmin

Being able to specify the time associated with a PV value would very helpful.

I have written applications that continue to gather data (in cFP units) in the event the PC crashes. If DSC allowed me to specify the time, I'd be able to use Citadel to log my data.

Lacking that functionality, I had to write my own version of Citadel from the ground up!

On the other hand...

I'm not sure how that would affect Citadel being 21-CFR-11 complient.

Ben

Caveman: So why is satelite TV better than broadcast TV?

Youngun: Instead of 3 channels you get 150 channels!

Caveman: What is a channel?

Reading the white paper on LabVOOP makes me feel like a caveman (or should that be cave bear ).

Can anyone recomend a OO for dummies type book or tutorial?

Ben

Of course, sometimes it's also very scary

Yes indeed!

Makes wonder what happened to the guy who was walking to the trash can.

Did he ever make it?

Did he fall in?

Ben

Wow! A big congratulations to Mike for reaching his 1k!

Even more importantly: thanks so much for getting the LAVA community up and running, and giving us all an independant place to mull over what we think is the greatest programming language in the world. Your impartiality, deep pockets and boundless support for the community certainly hasn't gone unnoticed, and is a great credit to you.

Congratulations Mike!

Ben

Okay, problem solved, or I should say problem worked around. It turns out that you cannot wire VISA Resource Name controls of different classes together, but you can wire from the property:values from one to another. You can also coerce from a VISA Session to a string and then from that string to a VISA Session of another class.

Go figure ...

Anyway, attached is two VIs that take a VISA Instr class in and give a VISA GPIB Instr class out. But if you try to wire directly from Session to Session they break.

Download File:post-45-1154550195.vi This uses property nodes

Download File:post-45-1154550232.vi This uses string coercion

This seems to work fine, so far, if anyone knows of a reason why not to do, this, ie, gotchas lurking, please enlighten us.

Why do I like these crash bugs so much?

Another approach type casts as a string and then to the target class.

This did NOT crash my machine and appeared to convert com3 and LPT1 OK.

Thanks for sharing Mike!

Ben

Re-test?!? There is no re-test for the CLA (yet) - you just get a new certificate and a "nothing significant has changed since you took the test" letter.

:question: Does that suggest that ExpressVI development is insignificant?

That was the case before the new versiobn of the course was offered.

We taught that course for the first time (our first time) on July 11th.

Now that the course is being taught, we should expect the test to change.

Ben

G'Day Peter and welcome to LAVA - it's great to have you here! For those who don't know Peter, he is the founder and president of Bloomy Controls and is a published LabVIEW author - a great resource for us here at LAVA

I very very rarely use them - usually when I'm trying to tech someone else a technique and need to fill in the blanks quickly. I never use them in production code. I tired to once (a long time ago, and maybe things have improved since then, but I haven't had a need to go back since), but needed to modify one of them a little, so I opened one of them up and was spooked by the horribly inefficient and amaturish code inside - it was quicker (and safer) to code what I was doing from scratch.

I looked the results of an Express VI thing once and was convinced I could to do it better and faster without them.

But on a related note...

Express VI Development has been added to the "LabVIEW Advanced Application Development" course (i.e. the one origianlly developed by VIE) and had previous served as the source of the more advanced ideas required for the CLA.

(Look what they've done to my song ma)

So I am going to look closer at that material JUST TO PASS THE RE-TEST!

Who knows, maybe I'll find something useful in there.

Ben

Contrary to popular belief, I have not sold my soul to NI...

...yet

Yes, "The devil is in the details." (Ross Perot ?)

So how am I supposed to reply to that?

Well since the topic is passing milestones let me point out another milestone.

BEER*

Dennis Knutson has now posted more than 8000 replies to the NI-Developer Exchange (Yes, I know the NI-Developer Exchange is evil).

WE have been posting some acks of his effort to help LV in this thread.

http://forums.ni.com/ni/board/message?boar...2&jump=true

But I am not posting to advertise that thread but to share a story that Dennis posted some time ago.

I repeat it here without permision.

"

I've got my own VEE story. Several years ago, I was hired to develop some LabVIEW software by a company that will remain nameless (sort of). I was given a cubicle and a rack of test equipment. It got a little strange because right around the corner was the development team for VEE. Not a team developing in VEE but the team that wrote VEE (see what I mean about sort of nameless). Swapped some stories and a few methods of doing some tests. At that time, VEE was not compiled and it took at least an order of magnitude longer to do some analysis routines in VEE. I was also approached and asked if I would like to switch from being a LabVIEW Alliance member to doing VEE programming. Doing a little market analysis, I determined that I would probably starve because of the lack of VEE users. I understand that VEE has since improved it's execution speed but it's market share is far behind LabVIEW. I've seen some figures comparing how long it takes to develop a LabVIEW program for GPIB instrument control versus one in VEE. One in particular seemed to be biased as the study was financed by Agilent but the end result seemed to indicate that an experienced programmer of either would take roughly the same amount of time. The problem is, there are many applications that VEE would take much longer or just be impossible to do. It does not have nearly the number of add-ons that LabVIEW does (try running VEE on a PDA or a real-time system or doing vision). It has hardly any native instrument drivers (they mostly use IVI or plug&play DLLs). Third party DAQ manufacturers will often have a LabVIEW library written and seldom one for VEE. These are the important factors for me and I would guess for the majority of users.

"

The original can be found here (see reply #9).

http://forums.ni.com/ni/board/message?boar...=146961#M146961

Ben

BEER* This is an invocation of Godwin^-1 Law to counteract the effect of mentioning the NI-Dev Exchange

... i have posted a lot of vi's for use with excel.

Which I appreciate greatly.

Thank you Joe for taking the lead on that effort! :thumbup:

Ben

Ok. Then I have to make an educated guess. NI turn over was 572 million bugs last year. Let's assume that about 40% of this is from LabVIEW so we get $ 286M for annual LabVIEW sales. Then let's assume that each user pays an average of $1500 per year for NI. So we end up to something like 200 000 users. So I assume the real number lies somewhere between 100 000 - 400 000 LabVIEW users around the world.

I would believe that number.

Ben

We've done the work for you: that's exactly what a GOB is. We have also done studies with several projects related to defense-related software metrics, including the LabVIEW/SLOC comparison, amongst others. Please feel free to send a message to me directly and I can have one of our experts contact you to talk through your available options.

We can count on you to keep us updated on the results of that off-line conversation, can't we?

Ben

First, has anyone developed a driver to communicate via the serial port with a Digi-sense 68900-11 temperature controller? I've checked ni instrument driver network, google, and the company's website with no luck. I think its manufactured by a company called Eutech.

Since I couldn't find a driver, I wrote a quick Labview interface with some simple commands to communicate with the instrument but couldn't get anywhere setting up the serial communication according to the serial communciation specification (see attached). I kept getting timeout's and was not able to read or write any data to the controller.

The basic settings are 9600,8,n,1, XON/XOFF (w/ XON=11 hex and XOFF = 13 hex)

So then I setup Portmon to watch the OEM's software application (which works fine). The OEM applicaiton seems to have a different setting for the "Shake:80" serial setting in Portmon. I've tried a bunch of different handshake settings using the VISA Serial Setup vi to try and match the OEM software to no avail. Also the OEM software seems to enable a bunch of Serial Events. Some of these I can enable and some I can't, but when I enable the events the computer justs grinds to a halt. Do I have to enable and handle the Serial Events or can I ignore them?

So I turn to you guys for advice. Attached is my code, the comm spec, and port mon snapshot's.

I saw your cross post to the NI forum and am responding here to let NI reply.

1) I believe the VISA driver has ben updated recently (to handl esomething with events). Have you tried the latest and greatest version (this week)?

2) THe are more than one "enable termination character" property. Check the "out of the box" version of the "Serail Port Init" that ships with LV.

I have nothing more to offer at this time.

Ben

This question has been asked quite a few times in the past... but NI hasn't told till now how many licenses they have sold/ sell per year.

I have tried to get this number myself and failed.

THe closest you can get is take a look at the user ID pages on the NI Exchange.

Example

http://forums.ni.com/ni/view_profile?user.id=70065

The "70065" is the user ID.

Play around with that number to choose other registered users.

That does not tell you how many user there are, just how many are registerd with NI.

Ben

I'm writing a paper on LabVIEW code metrics at the moment, and although I'm nowhere near finished it, here's a snippet:

I'm really excited about the GOB metric as it's the closest thing to a logical SLOC that I've seen in the LabVIEW world.

Nice Chris!

Leave it to VIE to do this first...

Ben

but certainly not 1 to 1.

Agreed.

I think it was JPD who was using a signature that said that a "single VI is word a 1000 lines of code."

But then again, I'd love to be working under that type of project estimating (provided someone funds it).

I have been using "VI" s where the VI is waht can be developed in an hour.

I am curious abou this subject as well,

Ben

I have not heard much mention of 64 bit (Windows XP) machines and LV yet.

I am having trouble getting the driver to work correctly when I deploy the LV application and driver to a 64 bit machine.

The 32 bit machines run just fine using LV 7.1.

I even tried it with LV 8 and the latest and greatest version of VISA and still no-go.

So....

Anyone been down this path before?

Ben

PS I also posted this Q to the NI forum see here

http://forums.ni.com/ni/board/message?boar...9&jump=true

Was there news about GOOP integration in this new version? :question: :thumbup:

When reading thru the release notes, I do not recall seeing mention of GOOP.

I do remember a rather long list of problems.

No I did not download it. Just looked at the release notes and then is wasn gone.

Ben

I Had also posted this Q to the NI Exchange here.

http://forums.ni.com/ni/board/message?boar...9&jump=true

There, Dennis Knutson suggested I right click on the "inf" file and choose "Isnstall".

THat was key to the adventure but I also listed some other notes in that thread.

So, I am OK for now and I hope the above spares others the pains I went through (or at least reduces the number of times you have to restore the backup)

Ben

FIrst lets get this out of the way.

"BEN, you did not write it down? You idiot!"

I have been using a driver that that was developed using by one of NI's internal consulting group using the "VISA Driver Development Wizard".

When I first installed it following the supplied instructions, it did not work.

I then called the NI Developer that did the development and followed his directions to get it working.

Now this is where the "did not write it down" part comes in.

I was so excited I proceeded to test and develop and did not write down whatever it was I did to get it going.

My memory says that I had to type something at a command prompt, I suspect it was registration realted.

So a year latter the customer now wants me to develop a duplicate of my original system.

Well it turns out the NI developer has quit and finding a resource to fill in the blanks is not happening real fast.

Has anyone here figured out what it takes to transfer the "driver" to another machine?

I will supply more details if that would help but I will save the bandwidth unless requested.

Ben

I don't really know how that happened. I pushed "add reply", and my reply ended up inside my first post although i wrote it at least 10 minutes after the first.

Anyway, are there any rules to this multitascing/multicore thing? Is two loops the only method, or are there more?

This NI KB article on Hyperthreading may help.

http://zone.ni.com/devzone/conceptd.nsf/we...6256e2900586d41

Ben

This link from NI site describes LabVIEW's multicore functionality. But - I have a dual core PC, and i have yet not seen a labview application that runs on both cores simultaneously. Are there some special tricks i have to do in the programming ? two completely separated loops or something?

Yes, two separated loops will do it (just tested) Rather cool actually to watch the CPU use when one loop is turned off, and only one core is running. But, this brings up some questions about the usefulness of this in a practical application where i need to transfer data between the loops.

It looks like you answered your own Q.

Yes it works just fine.

Ben

That sounds like an LV 7.0 problem. Do you remember seeing it on other versions?

Hi Yen,

When you get to my age you are happy with rembering things and being able to distinguish between memories and dreams.

Thanks for confirming that this is not just a dream. :thumbup:

I can not comment on what version of LV.

Ben

Contacted NI. I will post an update when I receive an answer.

This sounds familiar.

If you change the constant to a control does the problem go away?

Ben

I guess I'll try this technique. It does provide a bit of hiding that might prevent someone from tinkering with my typdefs.

Unfortunately, most of the icons I've seen are B/W with oversized abbreviated text that means little or nothing; not to mention missing any sort of description . When I make what I consider nice icons, I get comments that I have too much time or that I'm showing off!

I remember waiting for a TA to critique some code I had written.

The only feed-back I was offered was "Too many comments!"

Icons in LV, when properly used, are part of the documentation. In an application with hundreds of sub-VI's I can spot an icon I am after much faster than reading text.

Ben

I like this technique, too.

Ditto that.

Another variation is to put a typdef'd cluster in a sub-VI and bundle by name to produce what is similar to a "#Define" construct.

The sub-VI is used any time I would have used the "variable".

It yields similar to results of the "pre-compiling" in other languages. Change one place, and update realized in all places that need to know.

Do a nice icon and your development team members aren't even tempted to look inside.

Ben