BChandler

Here is my work desktop (only 3 labview version in here)

PJM

1980[/snapback]

Nice desktop clock. :thumbup: Were can I get one?

I use LV 6.1 mostly. Looked at 7.0 but nothing worth the money.

Still have LV 5.1 on the computer, lots of old jobs, and a copy of LV 4.1 around somewhere

This company's been using LV since '85 so some of the real old stuff is LV 3.1. I have the floppies but never needed them. (needs Win3.1) And originally AMI was in Quick Basic running on Dos.

But some of our customers are using each of these!

So my office is a Labview and DOS museum.

Showing your desktop is like showing your sock drawer.

You know everyones got one and uses it everyday.

But it's kind-of personal and only you can find things in it.

Related topic/poll:

What is your Desktop Icon and Shortcut philosophy?

A)Hate them, need a clean screen to think.

B)Make nice logical Groups.

C)Try to beat them back to one row per edge.

D)Spring clean when the picture is hard to makeout.

E)I love my icons! I just make 'em, I can't bring myself to kill one.

F)other_____________

I drifted from a B into a C.

-Bill

We almost never send the source code along with the executables but in every contract that includes software we have a support section that provides a number of hours of free support, including simple upgrades and equipment changes, each year.  Mostly that protects the customer from allowing someone without the necessary experience damage the end product.  Since we make high technology batteries that could get messy.

1434[/snapback]

Our companies policy is similar to the above. Only the exe is sold. With limited free support. If it is one of our standard products we will not sell the source. If it is a unique project, the device was developed for that customer, then we might sell the code. But try not to, since we have some of our own tools in it. But the main reason a company may require the source is just as protection if we disappear someday. In this case we can usually agree to set up an escrowl account with the source code in it, so if we disappear they get the code, otherwise they come back to us for updates. Or if we do sell it outright they can not re-sell it or even use it in-house on any other instument but ours.

Twice we did sell the code, to companies with no Labview experience. Then when they want a change I ended up giving them Labview lessons over the phone. And talking them through the change they wanted, while keeping my copy syncronized. A real pain with customers with no programing experience AND a thick accent!

But our case may be different than some, we make lab instruments not just the s/w.

Oh no. Please don't use global variables of ctrl references. If you absolutely must store the reference somewhere, use a functional global (while loop with shift register). Also, I'm NOT a proponent of writing directly to front panel controls from one VI to another because it makes code unnecessarily obfuscated. When debugging problems, it's hard to know what is coming from where.

5984[/snapback]

I understand where you're coming from. It's not a technique for beginners. But it has some powerful applications too. There is more discipline to it that I've mentioned. I make several Tag and Reference cluster arrays at init time and store these in a global. Then one, reentrant, program provides subsets of these references to other programs, in a library of core functions, based on Tag types. These then perform common functions for these tags without any additional code in the application. (yes invisibly, therefore somewhat obfuscated, but the presence of the Tag text gives something to track when debuging since each reentrant call holds the list of tags used at each location)

This allows common tasks to be carried out seamlessly, elsewhere. Like Data logging, Alarm limits checking and Scaling before and after I/O. Leaving the customer-specific main diagram virtually empty, except for the code unique to that customer.

This makes a core library that can be quickly copied from one job to the next. Growing more intelligent as it goes.

The key is to devise logical naming conventions for the tags, so they communicate their function just by the name. And syntax checking code can be added were needed to be sure all the needed tags are present, tag sets match, and find orphan tags, not handled anywhere. The Menu functions are also processed in the core. And the screen backgrounds are a collection of png files, created from a power-point file, made by the design engineer. As is the I/O list, from Excel.

It's been a very successful concept. I call it programming by reference, and use it in Altamira's BenchCAT

This will not help you. The Eval Formula VI works at run-time allowing formula parsing and evaluation. The Scripting VI indicated above is a development tool that creates a formula node during edit time. Here is a picture of the code so you can create it yourself in 6.1

5985[/snapback]

Thanx, for the diagram it was enough to get it working. Apparently LV 6.1 does not have the BDwin.Open property. But I made it work on an existing vi. Still as you said, of limited value at run time. I was thinking of a peak fit function we use as part of a larger program. Customers would like to define there own peak formulas. And I've avoided using Eval because there's too much data. Even a hard coded formula is slow sometimes. But the LV scripting in gereral is a neat tool.

Hi Bill,

Will there be other clients commnicating with this device?  I am just wondering, if it's only LabVIEW that will be communicating with this device, you can write the device driver for it in LabVIEW and use it as-is in the client portion of LabVIEW (without making it an OPC Server).  Writing an OPC Server in LabVIEW is definitely more difficult than an OPC Client.  And that too without proper documentation and device to test.

As for the OPC OpenG toolkit, I am not sure if it will be infringing upon DSC Copyrights.  May be we should start a discussion for this on OpenG.

Regards,

-Khalid

5974[/snapback]

Khalid:

This was just an idea to help in me test the Client s/w. So Labview is the only client.

Probably not worth the trouble. I'm going with plan B, work by phone with the customer in front of the device.

Once I have a single DataSockets data point working I should be able to guess at the rest.

But thanx for the reply anyway.

I've just started looking around this forum. Lots of cool stuff! wish I'd found it sooner.

-Bill

Use this and have fun.

Wolfram

5979[/snapback]

Could you make a version of that attachment in LV 6.1? (or is it a LV 7 feature only?)

This is a topic is of some value to me. The old Eval methode is too slow (and ugly).

-Thanx

great - thank you a lot

it works perfectly.

but i don't know why it has to be so complicate.

why don't they just use a reference id to communicate with a control,

like hypercard did : send (this message) to (control id x) ???

i think this aspect could really be improved

but it works !

2315[/snapback]

The above method is for dymanic references.

If you only need a reference to a few, static items

just right click on the item and create a reference.

This reference can be saved in a global varaible and acesses

by any vi.

Much simpler but requires manual creation of each reference

Use the general menthod if you want to create references to all

the items. And look at the Lable text to tell which is which.

I use both methods.

Not sure how a friendlier OPC Server would help...? Because with DataSocket (and DSC) ruled out, I don't see any other way of making LabVIEW an OPC Client.  Unless of course you plan on making your own OPC Client and calling it from within LabVIEW. 

Is there inetrest enough for an OpenG "OPC VIs" project? 

Regards,

-Khalid

5658[/snapback]

Good idea. I've used OpenG, very good stuff.

I have a related problem. I'm looking for a cheap (free)

OPC server to let me simulate the server for a device I don't have acess to.

I plan to use DataSockets to be the OPC Client and I have the spec. for the target OPC

server and need to write a Labview device driver.

But the customer does not want to ship the unit here and the vendor won't

send me a copy of the server s/w. I hate to write a bunch of untested code.

My only option now is to try something, send it to the customer for testing

and try again. He has limited Labview experience.

So a simple OPC Server written in Labview so I could customize it, would be nice.

But even an OpenG project would take too long. But it would be good to have.

Also can we write one without a copyright problem with NI's DSC?

-Bill