Mark Yedinak

QUOTE (twinsemi @ May 5 2009, 03:27 PM)

The exe from the first builder step works on the development computer.

The only additional installer is the NI-VISA Runtime 4.4 which has the distribution title "Setup", which is different from the other installers that are available. The others all say "National Instruments Device Drivers- November 2005, Disk 1" or "NI LabVIEW 8.0".

Without the VISA installer added, it builds normally, although it obviously won't work on a target machine.

Is the distribution title the key to the problem?

Try reinstalling the VISA from a none location. The installer is looking for the VISA runtime components required to include the VISA install in the application installer. The install builder is looking for the VISA stuff from where it was last installed.

QUOTE (Ton @ May 5 2009, 03:32 PM)

Functionally there isn't a difference between those two.

A reference gives the property node the power to operate on different controls, with this method you can place the code inside a sub-vi and call it several times for different controls.

Ton

Exactly. We use table quite a bit in our applications and over time we have built up a library of reusable VIs for manipulating the tables. This is one of those VIs. Others we have are for updating the contents of single cells, coloring cells based on their content, resizing the table as well as several others. In order to reuse these VIs we need to use a reference to the specific table we are manipulating.

Where I work we use the Agile process extensively. The product firmware is written in C and C++ and they use Agile to manage that process. We have also been using it for our LabVIEW development for our tools and automation. Agile itself is language independent so it can work just as easily with a LabVIEW development as it will with other languages. As for which flavor we use all I can say is that the Agile process that works best is the variety you customize to fit your environment. Many of our developers and managers attend the annual Agile conference and they have always returned saying that the folks who were most successful using it made the process their own. Pick and choose the parts from the different flavors that best meet your needs. The one thing that is good about Agile is that it really helps you to break your development down into small manageable tasks. It basically forces you to prioritize your efforts on small parts and do the minimal amountof work to meet the requirements of that task. It helps to keep you on focus for the task at hand and not try to create something that does everything all at once. The down side though is that sometimes it does lead you down the wrong path when a little more forethought would have helped to avoid that. Overall it works fairly well. In our environment we started using Wiki pages for our stories but have since switched to Sharepoint. Sharepoint is a bit more feature rich and makes maintaining the stories easier.

QUOTE (scls19fr @ May 5 2009, 02:13 PM)

Thanks but could you send me the .vi file because I need to know what property node you use

(because I use french version of LV not english version... so it's quite difficult without the .vi file)

Here is the corresponding vi.

Here is the block diagram from the VI I use to set the scroll bar position for a table. The only missing piece that you don't get to see is the subVI to count the number of lines in a string. However this is pretty easy to do.

I would use a single control which will allow the user to enter data and give you a single scroll bar. If you want to protect the data in the other columns and make then read only you can place a custom string control (which you color as transparent) over the columns you do not want to be modified. You then disable this control and the user cannot edit the cells below it. However the exposed cells are still able to be modified.

Since you mentioned the Agile process you may want to look at Integating Agile Development in the Real World. I would also recommend that you find some way to capture the requirements for your projects. If you go the Agile route this can be accomplished by writing good acceptance criteria for your stories. The Agile process also helps you to prioritize your development efforts and allows you to manage feature creep.

It sounds like you are doing something along the lines of a decorator pattern.

I basically rolled my own solution that appears to be very similar to the Open G and MGI variants. The main difference that I have is that mine are specific to the section being read. They are driven by typedefs but they mine do require modification if the typedef changes. I may look at converting mine over to use these other methods for the ease of updates. However with thta said I would recommend some form of text based ini file with typedefed clusters for the parameters. You should be able to reuse sections of your ini file in different applications (for example network configuration data) when you have common data. Over time you build up a set of specific sections in your files and your users get a consistent looking configuration file across your applications. If you are only writing one or two applications this may not be as important but it becomes more desireable when you are maintaining 20+ tools for your users.

QUOTE (crossrulz @ May 5 2009, 11:16 AM)

I have had to do this with some computers. Take out the hard drive and make it a secondary hard drive on a newer computer. As long as you don't muck around with what is actually on the hard drive, it should go back into the old computer and run just fine. I am also assuming you have another computer with ATA hard drive connections and not the SATA. This is also a good way of getting into people's "My Documents" :ninja: .

They do make external ATA hard disk cases which have a USB connection on them. Essentially this turns an old hard drive into an external USB drive. This is a good way to recover data from an old system. The boxes generally run about $70.

QUOTE (crossrulz @ May 5 2009, 11:16 AM)

I agree that this is what you need to do.

I would further add are you trying to modify code that was written in LV 5.0 using LV 8.x? If you are this will not work since NI only guarantees you being able to open code from two major releases back. LabVIEW 8.x cannot read LabVIEW 5.0 code.

Can you please provide a few more details regarding your problem. I doubt anyone will be able to give you an answer based on your question. It is far to vague.

QUOTE (ShaunR @ Apr 29 2009, 06:07 PM)

Read the thread again from 7 posts up.

Yes, and my statements still stand. NI provides means to install and uninstall the LabVIEW development environment for debugging purposes. I imagine they do for TestStand as well. However, neither development environments are required and therefore deployment costs for a TestStand system are limited to the TestStand deployment license. Systems generally aren't deployed which support full development environments. If that is what you want then yes there is additional costs but that is a different breed of a deployed product.

QUOTE (ShaunR @ Apr 29 2009, 10:26 AM)

We were talking about a full Labview development environment my comment was aimed at this

Since the OP said he deploys the vi's and anyone can change them (have to have labview on there for that). That is more than $500.

But the full development license of LabVIEW is NOT required to run a TestStand deployment. Trust me, we are deploying systems here without a full license of either LabVIEW or TestStand installed on the machine. The LabVIEW runtime engine gets installed and a deployment license of TestStand is installed. The only cost for the deployed system is the $500 TestStand deployment license.

QUOTE (ShaunR @ Apr 29 2009, 05:42 AM)

I'm thinking more about the cost of deployment. Exes and dll's are don't require licensing.I'd find it impossible to justify that the customer pays thousands for a full package which he/she never uses just so that they can use my software.

Actually a deployment license is only $500. Granted, you still have a license cost per installation but they do not have to purchase the entire TestStand license. These deployments work essentially the same as a standalone LabVIEW application with the runtime engine.

Jim Kring - I have been promising to talk to him about the Vi Package Manager and keep getting sidetracked. (Sorry Jim)

QUOTE (Prabhu_V @ Apr 24 2009, 01:05 AM)

Go to

Files>VI Properties>Window Appearance ..

Edit the Window title to the name you require.

You can also do this programmatically using a property node.

QUOTE (crelf @ Apr 23 2009, 11:19 AM)

You mean if, right?

True but one can hope. Just call me an optimist.

If you are only sending some basic pages to the server I think you would be better off building your strings and sending them via the native TCP connections. If you do a trace using your ActiveX version you should see what messages are being passed to the server. Your earlier version may have simply been missing a message that was generated by the ActiveX component. The TCP VIs are fairly basic. You would essentially need to use three of them. They would be the open, write and close VIs. More likely than not you will want to open the connection on port 80. What types of problems were you encountering?

QUOTE (Aristos Queue @ Apr 23 2009, 09:59 AM)

A non-trivial task? Really? So, in other words, you'd be impressed if LabVIEW could do that? We're always looking for features that would impress our customers... I'll let some of my developer buddies know that you'd like to see that in the August 2009 release...

:ninja:

I am continually impressed by all the "magic" that occurs under the hood of LabVIEW. This would be a great enhancement to LV when it gets added in the next release. This is one more reason that I think NI should get more aggressive about promoting LV as a general purpose programming language. It allows applications to benefit from current technology where other languages are still quite a ways off, at least with respect to the ease of using these features. However that is an entirely different topic for discussion. Anyway, feel free to pass along a job well done to the developers on my behalf.

QUOTE (GregSands @ Apr 22 2009, 04:30 PM)

I think there's a distinction worth maintaining, because LabVIEW doesn't do both things well.

• Concurrency is the ability to do multiple things at once - LabVIEW does this very well (parallel execution paths, independent for/while loops etc) and will utilize multiple processors/cores to run several different processes concurrently.
  
• Parallel processing is the ability to split a single task across multiple processors/cores, and LabVIEW doesn't do this well at all. Something like a parallel For-loop is needed; i.e. the ability to take a single section of code, and replicate it across several cores, hopefully also with automatic partitioning of arrays (or at least simple ways to choose how they are partitioned).
  

Cheers ~ Greg

LabVIEW does split code across multiple cores. It does this now and it does a fairly decent job of it. If however you mean taking a single FOR loop and splitting its iterations across cores then I would agree with you that LV does not do this. However this would be a nontrivial task. Currently though LV does run nodes (and I am using NI's definition of a node) on separate cores. It automatically schedules things for you. Granted, LV realtime gives you more control over it but it works on desktop systems too.

I still fail to see how you can say that a queued message is not generating an event. A message can be queued from anywhere at any time just like your interrupts. The event handler (the part of the code taking messages from the queue) processes them as soon as the arrive just like an interrupt handler. Also, an interrupt handler will only be working on a single event at a time just like a queue. The old Motorola 68000 family processors had 7 interrupt levels which denoted priority levels. In LabVIEW if you created 7 queues and had 7 parallel message handlers (one for each queue) your system would not behave any differently than a 68000 processor. What you do and how events are processed is up to the "interrupt" handler. You had to write the specifics of your ISR for the 68K too. In addition, since the 68K was single threaded higher priority interrupts caused the code in the lower priority ISRs to stop running. Only one thing could be running at one time on that processor. For multithreaded, multicore systems you still need to figure out a way for one task to stop another. This would is true regardless of whether you are using LV or not. Multiple priorities don't really solve this problem when you have multiple parallel tasks running since each task is independent. In addition if you are using a single queue for events you can always queue a high priority task at the front of the queue. This way that event will be processed next.

With respect to concurrent or parallel I think you are being a bit picky about the terms. Of course if you have a single CPU nothing every trully runs in parallel. However with multicore CPUs no LabVIEW does utiltize all of the cores. You don't even have to change your code for this to happen. I am not sure how old versions of LV would handle this but certainly the newer versions are aware of multiple cores. This is not true in the text based languages. You have to jump through quite a few hoops to take advantage of multiple cores with a single application.

QUOTE (jdunham @ Apr 20 2009, 06:56 PM)

Well, notifiers are a lossy queue of size one, with multiple subscribers allowed, and some bonus features, like wait on notifier from multiple, and notification history.

True, my "queue of one" for a notifier was an oversimplification but they are very similar in nature, especially with respect to events. BTW, queues can have multiple listeners too however the outcome is not deterministic. One listener will get the event but you don't really have control over which one if all listeners are waiting on the queue at the same time. Notifiers as you stated will allow each listener to receive a notification.

QUOTE (ShaunR @ Apr 20 2009, 06:21 PM)

Not wisihing to hijack this thread (perhapse start a new one? This could go on a while...lol)....but!

Well. It was a while ago (I weened on version 2.0...it came on floppies...lol). But I seem to remember creating monolithic executables. Deployment was a doddle

Perhaps this should be moved to a new thread.

QUOTE (ShaunR @ Apr 20 2009, 06:21 PM)

LabVIEW is inherently parallel in that to program parallel tasks all you need to do is drop two nodes next to each other. The underlying scheduler and task switcher will automatically run these pieces of code in parallel. Now with multicore CPUs LabVIEW can truly run them in parallel by running code segments on separate cores. The only "serial left to right" nature of LabView is the dataflow nature of the language (which also leads to parallelism) and programming style. There is nothing in LV that forces code to be executed from left to right if there is no dataflow. This is actually a common race condition bug that people make. They will put some node down on the right side of the diagram and think to themselves that since it is right of everything it will execute after the code to the left. In reality though once all of its inputs have been satifisied it will execute.

Creating parallel tasks in C or C++ is not a trivial task. You have to manually create your processes and threads. In LabVIEW this is all done for you. Drop two loops next to each other and you have parallel code. It is as simple as that.

No, queues are event driven. While waiting on a queue (or a notifier) your code does nothing. It is waiting for an event to trigger indicating that either an element has been queued or you have a timeout. Event driven means that your code is doing nothing until some event occurs. The code will effectively be using zero CPU cycles. (LabVIEW's scheduler will consume a few CPU cycles but the higher level code in your application will do nothing.)

QUOTE (ShaunR @ Apr 20 2009, 06:21 PM)

Notifiers are nothing more than a queue of size one. A notifier can only have one element "queued" at a time. Queues simply allow more elements to be placed on the stack. Event structures and VISA events are just different event types. Regardless, when using queues or notifiers you are writing event driven code. As for your disembodied code I suggest you try http://forums.lavag.org/Network-Queue-t11048.html&p=46805' target="_blank">network based queues. Since you already use notifiers it shouldn't be too difficult for you to use queues.

I don't have a picture but my kids like to give me crap about having an engraved name plat eon the back of my HP 48G calculator. I do get some payback now though because my oldest will be attending Rose-Hulman Institute of Technology this fall. They are home of the "Fightin' Engineers". Their campus isn't exactly a geek free zone.