ShaunR

Welcom Markus.

Not sure about a good time, but is always interesting

QUOTE (normandinf @ Apr 30 2009, 10:30 PM)

It doesn't exist. When you customize an XY Graph, you can see it's not selectable (not text). The Cursor Legend properties do not include Font properties, nor private properties (I checked).

You can change the fonts of the cursor name, but not the title "Cursor/X/Y".

Right...lol

So it must be impossible to do this then

http://lavag.org/old_files/monthly_04_2009/post-15232-1241128886.png' target="_blank">

Whats the micro controller expecting?

You can change the cursor legend font as with any other indicator/control.

Just set the font of the cursor legend to "Plain". Then they won't be bold.(If that's all you need to acheive).

QUOTE (bEMOL @ Apr 30 2009, 12:14 AM)

I already read the other forum link answers...

I am trying to do same thing... Could you do it?

Also, It is very interesting your the code shown in the requeriments.png

I wonder If you can share some example code to do it

Thanks a lot

If you want to programmatically add tabs to a tab control then use an active X container and browse for the Microsoft Tab Strip.

This has the methods to add, delete,clear etc.

http://lavag.org/old_files/monthly_04_2009/post-15232-1241110320.png' target="_blank">

There's an example in the Labview examples directory of a tank filling system. Might be worth a look.

QUOTE (jdunham @ Apr 30 2009, 02:45 AM)

I don't know all the details of LabVIEW threading, but I learned a lot from these forum discussions:

http://forums.lavag.org/Parallel-execution-t10870.html

http://forums.lavag.org/Templates-t13200.html

I'll take a look later...thanks.

QUOTE (jdunham @ Apr 30 2009, 02:45 AM)

You may be right. In fact, there ARE callbacks, in the true definition of callbacks (well in 8.6.x at anyrate). I've been playing with them for my event problem (well its not really a problem, it would just greatly simplify code and maintenance). But VISA doesn't expose the event refnum so you can't attach a callback. Or conversely, callbacks don't accept VISA resource sessions.There is/isn't/probably a way to get at it, but that aspect isn't on my priority list at the mo.

I would go one statment further. Labview is event driven (in the context of truly asynchronous events) with a callback, however C is not event driven....ever.

No. Your DAQ definitely won't be enough to drive the motor. Motors are high current devices. You will need a separate power supply and control it via that.

I agree with carlover in so much that really you need a dynamic tracking system (as well as it has been done before).

You will also probably want to go backwards and forwards, as well as up and down (since the sun tracks in an arc and starts in the east and sets in the west every day) so a single motor probably won't be enough (2) and they will need to rotate in both directions.

You might find this useful in thinking about what you want to acheive.

Solar Tracking Project

Although I'm at a loss as to why it took 13 weeks...lol.

QUOTE (Mark Yedinak @ Apr 29 2009, 09:53 PM)

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.

Read the thread again from 7 posts up.

Short answer "yes".

We need to know more too.

How are you interfacing to the motor (is it RS232 , PWM card, digital card, parallel port, force of will?).

Regardless of the interface, you will need a while loop that generates a timed pulse.

It'll look something like this

There are many examples in the Labview examples directory. I would take some time to look at them as quite often you can modify them to suit your needs.

QUOTE (Mark Yedinak @ Apr 29 2009, 03:50 PM)

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.

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

QUOTE

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.

QUOTE (shoneill @ Apr 29 2009, 02:03 PM)

If you have registered for an event and the event fires one of the parameters passed at the left-side of the event structure is the actual event refnum. In my mind this does not belong there but you could theoretically close this reference and kill all other processes "listening" to the event in other places.

Shane.

Ah. Thats not it then. I'm looking for a way to link events from dynamically loaded vi's So that the vi can basically "hook" the existing event mechanism.

QUOTE (shoneill @ Apr 29 2009, 08:12 AM)

There is a workaround to get at the actual event using the Event refnum when the event in question actually fires

I think that's what I'm missing for me to use events effectively from within an encapsulated architecture.

Whats the workaround?

QUOTE (manojba @ Apr 29 2009, 08:00 AM)

Hi, how to create hypertext link in labview i have splash screen for about button, in the splash screen I have my companys website link as of now its a underlined text how to make it a hyperlink so when somebody clicks on it it should open the website thanks in advance...

Hmm. Got me thinking. This would be a good one for a Coding Challenge.

Who could write the best URL Label XControl.

Be nice to be able to just plonk one on the FP.

QUOTE (jzoller @ Apr 13 2009, 09:40 PM)

The LV development environment is very useful in debugging on the fly if you have live code. NI even supports it with a licensing option.

... yes, I know, everything is always tested before it hits the floor, and no one would ever dream of pig testing so that widget can ship by Friday. Right?

Joe Z. (not my current employer, btw)

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.

QUOTE (candidus @ Apr 29 2009, 09:02 AM)

In LV7.1 you can open a VI reference to a VI that resides in a DLL or EXE.

Wire its path to the "Open VI Reference" primitive,

the parent "folder" of the VI is the DLL or EXE.

But I think things get complicated if you want to use DLLs/EXEs

built with different LabVIEW versions.

Much better solution.

The "Specify path on diagram" is the way forward but I don't think that exists in 7.1 (long time since I used that). So you would have to use the old method of creating an intermediary DLL which you can call from the "Call Library Function node" to pass data too and from other the other DLLs. (2D array in and out always worked best for me). Not elegant, but it works.When you create the plugins, if you make their inputs/outpts are a 2D array then your intermediary dll only needs 2 inputs (the dll name and the 2D array) and one output (2D array).

QUOTE (jbrohan @ Apr 27 2009, 02:30 PM)

Hello

I have the need to read MMS without going to a cell phone aggregator company. The approach I offer here is not at all an example of good programming practice and it would be much better to gain access to a cell phone company's database. Maybe this will happen when the system gets going.

These MMS are sent to a phone number, and then picked out from the picture messaging web page. I used the iMacros product to see if it could be done simpler, but found that there was just not enough control. Th iMacros can click on a position on the screen, but prefers to activate the links inside the HTML.

The best that can be said for the method is that it works (at least until they change the web site again!)

The vi's to enter text into a web page and to click the mouse are included.

If I remember correctly, you can hook IE using active x to get click info. Might solve your positioning problem.

I'll see what I can dig up if your interested.

QUOTE (PaulG. @ Apr 27 2009, 05:44 PM)

Agreed. I just spent my lunch reading through this. It's reading like a preamble to a crusade.

You can always ignore us (like 90% of the lurkers ). Or you could read it during work time when your paid for it...lol.

QUOTE (jdunham @ Apr 27 2009, 04:09 PM)

Unfortunately my data isn't "bursty". It is multiple continous streams with control on top. No problems either.

QUOTE (jdunham @ Apr 27 2009, 04:09 PM)

If I were to adopt the same strategy in the current project I would end up with 87 queues

QUOTE (jdunham @ Apr 27 2009, 04:09 PM)

Ummm. Are you referring to spawning multiple (200+) threads like in the BT client? I don't think that is possible. Especially if you can only have cores x 4 threads.

QUOTE (jdunham @ Apr 27 2009, 04:09 PM)

So I guess your in the Q or die camp (but suspected that quite a few posts ago)

QUOTE (jdunham @ Apr 27 2009, 09:41 AM)

Why would you use a queue if the producer is faster than the consumer? That's what notifiers are for.

Quite the converse in fact. You would use a queue to "queue" ( or buffer) the messages/data/etc (because you can't process them fast enough) in the hope that they may ease up later so you can get through the backlog.

QUOTE (jdunham @ Apr 27 2009, 09:41 AM)

Because you may be busy doing something else that is time critical and higher priority.

QUOTE (jdunham @ Apr 27 2009, 09:41 AM)

So many why's. I've already explained that one.

QUOTE (jdunham @ Apr 27 2009, 09:41 AM)

How can you not? Since there is data in the queue how does it know that its not for it? Thats what I call the nature of queues.

QUOTE (jdunham @ Apr 27 2009, 09:41 AM)

Don't get all Trekky on me now And I know why as queue is useful, in the same way I know that a car is useful unless you in a swamp.

QUOTE (jdunham @ Apr 27 2009, 09:41 AM)

Do a search on "kill Bush" and you get 12,700,000. Your point is?

This is what NI have to say on it:

http://zone.ni.com/devzone/cda/tut/p/id/5317

QUOTE (jdunham @ Apr 27 2009, 09:41 AM)

For asynchronous behaviour they are already in while loops. If data is lost, then I'm not really sure what you were trying to demonstrate with the example.

QUOTE (jdunham @ Apr 26 2009, 06:29 PM)

OK, I think we're converging: like queues and notifiers, think state machines are over-used. We're also proving that the way I spend my weekends is lame. Hopefully this is the last time I'll take the bait.

As lame as my weekends eh?

we may have converged on a spin-off topic. But you are still quite a way from convincing me that queues are "the magic bullet" and all applications should use this architecture.

QUOTE (jdunham @ Apr 26 2009, 06:29 PM)

Oooooh. No. Because then the UI would have to wait on the notifier(s). Also if you go down this path you end up with notifiers everywhere like a plague of mosquitos. A pain in proverbial to debug. All I have to do to debug is watch the global. There is no need for sequencing so a notifier is not useful.

QUOTE (jdunham @ Apr 26 2009, 06:29 PM)

I started this thread after a comment in another thread that suggested a fairly simple implementation would be better as a queue. I asked whats everyone fascination was with queues on this forum. As a newbie to this site, as I looked at more and more posts it seemed everyone was queue crazy and the remit was...lets start with a queue and make it all fit. So Rather than hijack the thread, I started a new one to find out why people thought (and I think even you said this too) queues are "the magic bullet" to application design.

All applications have some degree of asynchronicity that doesn't mean you should design around a queue. It sounds almost as if you are agreeing with me in repesct to queues adding complexity

QUOTE (jdunham @ Apr 26 2009, 06:29 PM)

The only problem with globals arises when you require synchronisation. But that isn't really a problem, it is (a very useful) feature of globals. The fact that it creates copies of data is a drawback (if you were running on a ZX spectrum...lol). But a queue isn't a replacement for globals as you point out in your example (removed the stop button from the user). And even in the first example it was used.

QUOTE (jdunham @ Apr 26 2009, 06:29 PM)

I did say that distibuted IO (which is I think what you are describing) is one scenario that would warrant a queue. However, yours is a large app as I seem to remember (how much of that is event management and interprocess comms?) and certainly realising the BT client wasn't a large app because Delphi is event driven therefore very suited to the task. Horses for courses.

QUOTE (jdunham @ Apr 26 2009, 06:29 PM)

Queues do not have a wait function. Yes you can get similar behaviour IF you only ever have 1 message on the queue at asny one time, but if your producer(s) is faster than your consumer this is rarely the case. Therefore having an indefinite timeout makes no difference as your sub process still needs to inspoect the message to see if it was meant for it. So it is not sleeping, it is inspecting. You would then need a case for if the message wasn't for it and you can't just let it run through a tight loop so a wait so many milliseconds would be needed. So it's not sleeping evertime there is a message on the queue regardless of who it is for.

QUOTE (jdunham @ Apr 26 2009, 06:29 PM)

Ummm. It doesn't do what it says on the tin.

It uses no globals, because you have removed the "Stop" from the user in SubVI1. The original example uses a global also.

In the example I posted (ver 2), I set the aquisition time to 0ms and could acheive 3 ms of aquisition (mainly due to the 1ms delay I have in my notifier VI). All of the VI's show 3ms and all the vi's show the same loop iteration thus proving they are all capturing the aquisition "Event" with no loss.(well. The aquisition VI might show one more since it gets an extra go after you press stop on the aquisition vi).

In yours, however. If I set it to 0ms the aquisition vi runs like the clappers (6229 for the length that I ran it) but the others show significantly less (2654). What is happening to the other 2654 samples of data?

QUOTE (Aristos Queue @ Apr 26 2009, 08:50 PM)

Let me assure you -- it really does go to sleep. There is no CPU load at all from a sleeping queue prim. There is no polling for data. Thread A executes and goes to sleep on a queue. Thread B runs free. When Thread B puts data into the queue, it wakes up thread A. In fact, it doesn't even put the data into the queue. It puts it directly into the output of Thread A and A wakes up and starts running as if it had just gotten the data out of the queue.

Shorter ones first...lol.

Even if there IS data in the queue but not for that "thread"?

And (just a point to fill my knowledge gap) Are you saying that 2 while loops (or 50 even) will run in their own separate threads?

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

I'm not exactly sure what you mean. I think the event structure is queued. If you invoke two or more value(signalling) properties then they will be handled on a FIFO basis, since there is some kind of queue behind the event structure. I agree it would be cool if LabVIEW made it easier to handle user and programmatic events in the same structure. I know you can register your own event, but it seems like a pain to me, when the queues are so easy.

Event structures and queues both have the problem that if the handler code is not fast enough, you'll fall behind and either miss events or stack them up with high latency, either of which is undesirable. You can programmatically trigger event structures with the Value(signalling) property, which makes them act a lot like... queues.

What I actually meant was why do you use notifiers to receive updates when you are using a queue anyway for events. I've just read it back and see that I phrased it badly (the subject before being events) it was in response to the previous paragraph which finished with

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

I tend (generally) to use one or the other as in many cases as (you point out later) their features can be seen to be synonymous.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

I use an appropriate strategy. Not really answering your question though, I know, but I'm not sure of what you have in mind. I tend to think through the partitioning and use encapsulation to distill interaction between sub components to a bare minimum and make each aynchronous task as autonomous as possible.

Generally it boils down to an error indication, start, stop and pause.

But I will give you a very typical example of an every day scenario that would be very complicated using events/queues/notifiers etc. But Labview makes very easy and can be done it minutes.

Lets assume the system is monolithic and only runs on one machine (a test/inspection machine for example) and say I have 32 digital inputs that indicate alarm conditions on of which only 8 of them are to be displayed on the user interface. I can (and do) arrange with the electrical guys that those 8 are all on the same port (I give them a spreadsheet with the pin numbers of the DIO device and define which sensors/outputs will be attached to what).Now I can have an asynchronously running digital input VI that all it has to do all day is read the status of those digital inputs and write them to a global as a 32bit number. Then I can easily mask them off in the user interface just by polling that global and (with the number to boolean function) show the user which ones they are in a 1D array of booleans or I can use the number as an index into an array of strings to show an error string. If you have multiple banks (like 128 in banks of 8) you can partition those banks for each hardware subsystem). Then your on-screen alarms become a 2D array of booleans, each row (or column) associated with each piece of hardware. Any other VI can also read that global if and when it wants to (none of that critcal section rubbish with Labview ). So if some other part of the system needs to now about it it can. Quick, simple and as I said takes a few minutes.

Now. This test machine needs to feed a part from a bowl feeder into the test/inspection section. Again. I create a "Bowl Feeder" vi that requires a Start (give me a part), Stop (shutdown), Pause (wait a mo 'cos somethings wrong) and error (or no error if everything is ok). I don't need a response that a part has arrived because that will be given by a sensor.

So I eventually end up with all these autonomous, asynchronous subsystems (each only requiring a start, stop, and pause). The start is usually from the main sequencing engine (single notifier if everything happens in parallel or one for each if they are staggered). The stop and pause can be a global (similar to that used in my previous posted example) and the subsystem handles its own errors and pauses all the other subs and the sequence engine while it figures out what to do about it and invokes the shut down procedure if it can't do anything.

Now. Distributed IO is a different kettle of fish!

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

I have always had the UI in its own loop. I used to "break" the link with globals and dynamic loading (the example I posted would have used globals instead of notifiers and would have been quite messy), now we have other tools like events, notifiers, queues, semaphores and the like. We have the tools to make more elegant solutions.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

I do rarely use them (in the way that they are often used). Not because I don't like them, but because they don't warrant the use in a lot of the systems I design (take the example above). I could use them, but a couple of notifiers and a small global do the job without having to define messaging scheme for interaction. If it were a distributed system or a supervisory system where a lot of information is being exchanged, then yes it would warrant it, but not just for a start, stop and pause. I'm an advocate of the choosing the right architecture for the specification rather than just throw a queue at it, which it strikes me a lot of people seem to be.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

See above

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

In the above example and in the case of an alarm dialogue. It would set the pause flag while it is on-screen (if that's whats required or it might just log it to a file...depends). Crowbar all the subsystems and invoke the "graceful shutdown.vi" on a reset or stop. And un-set the pause flag for a cancel. . Triggers would probably be hardware and catered for by the the individual subsystem responsible for it.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

That depends on how much info they need to do their job. I prefer autonomous encapsulation of the task as it makes the code a lot more understandable and intuitive (and less documentation )

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

I think I see the where the difference in views lie. I don't see dataflow as a limitation. The fact that it is a a dataflow paradigm, means that you don't have to worry about state information. The function (or vi) gets executed when all its inputs have data. Its implicit. In event driven languages (I also program in Delphi and C++ by the way) you have to have a lot of state information to make the application work in an ordered fashion. This is unnecessary in Labview which is why it is fantastic for test/automation/inspection etc but sucks as a webserver (although NI would like to think its great). I recently wrote a bit-torrent application (lots of concurrent connections appearing and disappearing at random, asynchronous pipes etc). Wrote that in Delphi because it would be a nightmare in Labview. Square pegs don't fit in round holes.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

Ditto. They hide functionality, can be difficult to conceptualise and break dataflow. That said. They do have the advantage that they compact code and enable selective branching. If used spareingly a definite asset. But often abused. I think were on the same page there

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

First off. I don't consider the former to be the "wrong way" just "another" way. There are many tools at our disposal and we should choose those that are appropriate. As I think I said in the notes. It was to demonstrate that the use of queues adds complexity and obfusification. It took me about an hour to write that, debug, benchmark and comment it (with coffees). I expect the same cannot be said for the original (excluding the pictures and write-up I mean). It may have been an illustration. But there are many out there that would do just such an app that way.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

Better? No. They both fulfill the spec. I think one is easier to read and understand because it uses Labviews dataflow more and the other is more complex and difficult to read because it breaks that dataflow and adds complexity to compensate.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

No. My thesis is that queues add complexity, are cryptic and (sometimes) require more VI's to be modified throughout the code. And that should be taken into account when designing a system since other alternatives can yield a more intuitive and easier to read solution and have better encapsulation.

QUOTE (jdunham @ Apr 25 2009, 08:12 PM)

One observation. It doesn't "go to sleep" it polls the status until it has something in the queue. So I'm guessing you have a wait so many milliseconds in the timeout case. That is the big difference between queues and notifiers. If you add another notifier (wait) to my example before the acquisition another after the AQ notify in the Subvi 2 (notify) and a third before the while loop in the main (also a notify just to kick off the aquisition in the first place) then you can run the system fully synchronised, flat out with no loss of data (3ms). You can't do that with a queue.

See attached:

Download File:post-15232-1240703966.zip

And if you read all that your a star....lol.