ShaunR
-
Posts
4,856 -
Joined
-
Days Won
293
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by ShaunR
-
-
Wire an indicator to the Standard out and you will see the result from your call to the DOS box. You don't get an error because the SystemExec successfully completed the CMD call. However, the DOS box may not have executed the copy command.
If you look in the windows help, they suggest making a batch file with the command options and calling that.
I personally would use a "Call Function Block Node" to call a windows API to achieve what you are trying to do. (Kernel32.dll has a SetFileTime function). Although there may be an easier/more elegant method.
-
QUOTE (jdunham @ Apr 21 2009, 09:23 PM)
QUOTE (jdunham @ Apr 21 2009, 09:23 PM)
With any event driven system, the maximum amount of time an event takes to be handled determines the latency of the system to handle new events.It would be nearly pointless to use any event-driven system to handle a 10-minute monolithic process. If you need to handle other events, you can usually break up a long process into many successive events, and throw the follow-on events from inside the handler. That's a state machine, which is another great use for a queue.Are fou saying that VB, C++ or Delphi couldn't handle a file search? (of course your not
) A file search can take more than 10 mins and when it finds a file matching the search criteria, raises an event (usually with passing a search record). The main program is just sitting there (animating an icon, refreshing the display, picking its nose) untill the event tells it its found something.I'll start another thread about Labview, state machines and why windows programmers love them....lol.
QUOTE (jdunham @ Apr 21 2009, 09:23 PM)
But I've just been convinced that Labview is parallel in nature
). Surely we just parallel up our slices until its big enough for our complete task 
QUOTE (jdunham @ Apr 21 2009, 09:23 PM)
No, the major difference is that queues are FIFO, and notifiers are broadcast events with no history. If your notifier handler is not fast enough, you will lose events rather than stacking them up and falling behind like a queue would.Indeed (well 50% indeed anyway). Queues are a particular type of buffer where only the first and last elements are accessible (FIFO,FILO). If your consumer is slower than your producer (as in my example), your buffer (queue) will just increase until you reach a limit (resources or you've fixed the length of the queue). However, with notifiers, if your consumer is slower than your producer your producer can just sit idle until it receives some indication (another notifier perhaps) that the sub process has finished. A queue based system demands that things are taken off the queue faster than they are put on the queue. Notifiers do not have this limitation (but they do have limitations). The consumer is idle until a start "event" has occurred and the producer is "idle" until the "process complete" event has occurred.
I'm not anti-queues. I just don't think they are the magic bullet to program design which some people (not necessarily on this forum) seem to think they are.
QUOTE (jdunham @ Apr 21 2009, 09:23 PM)
I've still got Marks post to do
QUOTE (Mark Yedinak @ Apr 22 2009, 06:40 PM)
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./quote]A queue doesn't generate events, neither does it react to events WHEN they happen (which is what is meant by event driven). I would consider an OnQueue or OnDeQueue to be an event that would be "generated" by a queue (which doesn't exist in Labview). Your queue implementation is a history (or buffer) of "events" that have occurred at some point in the past and the order in which they occurred (user clicks something on screen, DAQ, VISA or whatever). It is an extension to the logging example in the examples directory.It will only process these historic events if it is at the front of the queue therefore it will only process it immediately if there is only 1 in the queue (queue of one sounds familiar)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 usingLVor 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.Whew. What a lot of effort to mimic a 20 year old single threaded processor
. This example, however, is a good example of interrupts interrupting interrupts.The key point here though is that WHEN the interrupt occurs "code in the lower priority ISRs to stop running"! Not "the interrupt will be serviced IF the request is at the front of the queue".
QUOTE (Mark Yedinak @ Apr 22 2009, 06:40 PM)
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 ofLVwould 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.I think Greg answered this better than I.
-
QUOTE (Mark Yedinak @ Apr 21 2009, 12:45 AM)
QUOTE (Mark Yedinak @ Apr 21 2009, 12:45 AM)
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.I will concede Labview "parallelism" but I I think we are talking about concurrency and I would wholeheartedly agree that labview runs concurrent tasks but not parallel code. But it's not an area I'm an expert in and perhaps I'm being too pedantic (I don't really care how it works as long as it does...lol).
You are right though multithreading in C++ is not trivial. It is in Delphi though
QUOTE (Mark Yedinak @ Apr 21 2009, 12:45 AM)
. Since you already use notifiers it shouldn't be too difficult for you to use queues.I see events rather differently.
Events (to me) are analogous to interrupts. Events can occur in any order and at any time and, on invocation, handler code is executed. A queue in Labview, however, does not generate events rather (from what you have described) you are taking the presence of data to mean that an event has occurred. You don't know what event has occurred until you have popped the element and decoded it The order is fixed (the position in the queue) and presumably, while this is happening, no other "events" can be processed so they cannot occur at any time (well perhaps they can occur at any time, but not be acted upon). The major difference between notifiers and queues is that notifiers can occur in any order and at any time and the "handler" (the section of code waiting) will be invoked.
I would be interested to see how you handle priorities with a queue. Lets say (for example) Event 1 must always be executed straight away (user presses Emergency Stop) but event 2 can wait (acquisition data available. And just to be annoying, lets say processing the acquisition data takes 10 minutes and you've got 100 of them in the queue when the e-stop comes in ;P ).
In an event driven environment, when Event 1 comes in its handler can check if the Event 2 is running and stop/pause it or postpone it (cut power and gracefully shut down acquisition).
-
Not wisihing to hijack this thread (perhapse start a new one? This could go on a while...lol)....but!
QUOTE (Mark Yedinak @ Apr 20 2009, 11:20 PM)
Didn't most versions of LabVIEW executables require the run-time engine? At least this is what I recall from as far back as LV 4.0.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
QUOTE
Since LabVIEW is inherently parallel in nature you always need some mechanism to pass data between parallel tasks and to synchronize them as well. Queues naturally do this. Unlike a global variable queues provide synchronization as well. In addition they are event drvien so you can avoid polling local or LV2 style globals. They are also very efficient with respect to performance.Actually Labview is inherently serial in nature (left to right). That is why you have to resort to other techniques to manage parallelism. I also fail to see how they are event driven given that you put something in the queue and take things out...nothing more. It is a serial buffer with access to only the first and/or last entry in the buffer.
I don't tend to use queues much, but I do extensively use notifiers for passing data and synchronising, which aren't really event driven either in so much you can wait for a notifier and it will get triggered. The only truely event driven features in Labview are the Event Structure and VISA Event. But linking events programmatically accross disembodied vi's (which I use far too often); I've always found troublesome.
-
Am I right in thinking you would still have to have all the "NI stuff" anyway? (i.e the run-time engine).
Oh for the days of standalone executables !
And what is this obsession with queues on this site?
-
-
QUOTE
If we would abandon the idea of remote acquisition over ethernet would there be a way to condition a voltage signal (more or less constant) to be reliably read from a distance of 600ft (200m)?Sure there is. Current Loop
-
Hi Peeps.
I thought I'd put this out into the wild before completion because I'm not going to get around to it again for another few months and as I've not seen anything else around; thought it might be useful.
It's a partial implementation of the OBEX protocol with an example of the OBEX Object Push Profile over bluetooth for sending files to mobile devices (vards,vcalendars, images,music etc).
Load up the BT Push File.vi (top directory) and set the address and you should be good to go to send files to your mobile phone.
The example has been tested on both the Microsoft and Widcomm stack to send files to samsung (U600, i8510) and nokia (N95,N81) phones without any problems, but (as with any new software) I am expecting a few teething problems so let me know and (no promises) I'll see what I can do.
If you are using the Widcomm stack. I would suggest pairing first because Widomm requires authentication and the authentication manager takes quite a while to pair so you will time out. The Microsoft stack doesn't require authentication first so need to pair at all.
-
-
OK. I understand.
I would be very tempted to just make your display a 2D array of strings (first column can be a label if you want). Then regardless of what data it is you can just format it in whatever manner you think is fit and append it. If it doesn't exist it will just appear as a blank (or you can insert N/A or whatever). If you hide the fact that it is an array, it will just look like a multi-line label. If you add more fields later, just make more elements visible. if you redefine fields , just change the labels (if you have any).
The question I haven't asked properly is this. Is your problem just a method to display the info, or is it some intermediate stage that the data in your fields will be processed later?
-
QUOTE (Val Brown @ Apr 17 2009, 04:44 PM)
Shane et al: Yes that's what I thought but I guess the background implication in asking it that way is: Why isn't it internet enabled and/or why can't that be done just for this one operation?CRELF: Yes, I'm sure you're right because the only possible timeline I've heard discussed is that scripting will be released AFTER all the toolkits are implemented for Linus and Mac and the timeline for THAT to happen was something like "...when Bush gets elected for the third time."
Because our IT is analy retentive.If I connect it to "THEIR" network then they have to have ownership which means the following:
1. Cannot take the lid off to install cards. Have to send a support request to get the card installed which may be in 2-3 days time if I'm lucky. If found "tamperig with company property"....written warning
2. No administrator priveleges. If software needs to be installed...Yup..you guessed it..Support ticket...2-3 days.
3. Must have a defacto desktop/laptop PC with all the their crap and must use XP even if the customer wants Vista.
4. The licence would have to be in one of their names (as you know...NI only supply support to the name on the license) so they can provide me with support <img> which means that yet again I would have to send a support ticket to get them to phone NI to asks a question which they know didly squat about.
I will just point out though that I do have number 3 also. They decided that a dual core (not even core2) 1.6 GHz Toshba laptop with 512MB ram and a 20 Gig hard-drive is an adequate Labview development platform. It takes 20 minutes to boot in the morning if connected to the network because of their policies.
Because of that, I run Labview, labwindows, test stand and all the toolkits on an industrial PC on it's own network where I can do what needs to be done. When it needs to be done.
We actually rate our IT department as a project risk. The less involvement...the better.
So. It is a real pain but the alternative is worse!
-
Chatty embedded engineers?
That's an oxymoron isn't it?
-
Diogenes of Sinope.
Because we are all a bunch of cynics and perceived as criminals by text programmers.
-
Everyone will have their own methods and solutions to this one. It's an old problem with many equally correct solutions.
If you give an example stream and header structure we would probably be able to justify each approach better and you could pick the solution that best fits your preferences.
I find, generally, the best option, if possible, is to find the super set of the protocols and choose a display method that can cope with all of them.
what do I mean by this...Well...
Lets say your devices both send a header consisting of a command byte, a length byte and the payload (nice and simple). In device 1 the length byte is 2bytes long but in device 2 it is 4 bytes long. The length byte of both devices can be represented as a 32 bit number so you would choose that to display the length. Just in case the hardware engineers decide to use a bigger length in the future you could even go for 64 bit integer.
Now. slightly different (but following the same approach).
Lets say we want to represent the command byte with human readable strings.
We could use a menu ring (since arbitrary and non consecutive values can be assigned to its strings). We could then assign each string with the value directly from the command byte - job done for device 1. Now there are two ways of coping with device 2 depending on how much similarity there is.
1. If most of command bytes are exactly the same and the extra ones are just extensions to the original protocol (device 1, MkII) then we have already done most of the work and we only need to add the extra values to the menu ring.
2. If the command byte of device 2 use the same values as device 1 but mean completely different things (usually different devices) then add...say 100 to the command byte and assign the menu ring strings for that device command byte +100.
So. 2 devices, 2 different headers and we display a menu ring and a U64.
If they add more commands...we just add to our menu ring. If they change the number of bytes (up to 8 anyway), we don't need to change anything. You can extend this for the payload too (up to a point
) -
-
Perhaps the mods can re-title this for me then.
OBEX FTP, Looking for a FREE protocol spec.
-
-
Nope. It's not online.
-
-
Oh. And just remembered!
there's a login example in the examples directory :;
-
lol..
Can't see for looking.
Feel stupid now!
-
QUOTE (crelf @ Apr 6 2009, 09:05 PM)
Of the following two methods to build a vi global. Which is better?
http://lavag.org/old_files/monthly_04_2009/post-15232-1239919373.jpg' target="_blank">
-
One of my old gripes since version 2.0 about the development environment.
-
And when I post the result in the code repository, I'll remember to charge you if you download it!
Reduce 2D Array into 1D Sequence
in LabVIEW General
Posted
QUOTE (neBulus @ Apr 22 2009, 09:47 PM)
And means that you can convert n-dimensional arrays